Changes in Makefile

edae1f06 - perf/x86/intel/uncore: Parse uncore discovery tables

Wed, 17 Mar 2021 17:59:33 +0000

perf/x86/intel/uncore: Parse uncore discovery tablesA self-describing mechanism for the uncore PerfMon hardware has beenintroduced with the latest Intel platforms. By reading through an MMIOpage worth of information, perf can 'discover' all the standard uncorePerfMon registers in a machine.The discovery mechanism relies on BIOS's support. With a proper BIOS,a PCI device with the unique capability ID 0x23 can be found on eachdie. Perf can retrieve the information of all available uncore PerfMonsfrom the device via MMIO. The information is composed of one globaldiscovery table and several unit discovery tables.- The global discovery table includes global uncore information of the die, e.g., the address of the global control register, the offset of the global status register, the number of uncore units, the offset of unit discovery tables, etc.- The unit discovery table includes generic uncore unit information, e.g., the access type, the counter width, the address of counters, the address of the counter control, the unit ID, the unit type, etc. The unit is also called "box" in the code.Perf can provide basic uncore support based on this informationwith the following patches.To locate the PCI device with the discovery tables, check the genericPCI ID first. If it doesn't match, go through the entire PCI device treeand locate the device with the unique capability ID.The uncore information is similar among dies. To save parsing time andspace, only completely parse and store the discovery tables on the firstdie and the first box of each die. The parsed information is stored inanRB tree structure, intel_uncore_discovery_type. The size of the storeddiscovery tables varies among platforms. It's around 4KB for a SapphireRapids server.If a BIOS doesn't support the 'discovery' mechanism, the uncore driverwill exit with -ENODEV. There is nothing changed.Add a module parameter to disable the discovery feature. If a BIOS getsthe discovery tables wrong, users can have an option to disable thefeature. For the current patchset, the uncore driver will exit with-ENODEV. In the future, it may fall back to the hardcode uncore driveron a known platform.Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/1616003977-90612-2-git-send-email-kan.liang@linux.intel.com List of files: /linux-6.15/arch/x86/events/intel/Makefile

fd3ae1e1 - perf/x86/rapl: Move RAPL support to common x86 code

Wed, 27 May 2020 22:46:55 +0000

perf/x86/rapl: Move RAPL support to common x86 codeTo prepare for support of both Intel and AMD RAPL.As per the AMD PPR, Fam17h support Package RAPL counters to monitor power usage.The RAPL counter operates as with Intel RAPL, and as such it is beneficialto share the code.No change in functionality.Signed-off-by: Stephane Eranian Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20200527224659.206129-2-eranian@google.com List of files: /linux-6.15/arch/x86/events/intel/Makefile

b2441318 - License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Wed, 01 Nov 2017 14:07:57 +0000

License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseMany source files in the tree are missing licensing information, whichmakes it harder for compliance tools to determine the correct license.By default all files without license information are under the defaultlicense of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'SPDX license identifier. The SPDX identifier is a legally bindingshorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart andPhilippe Ombredanne.How this work was done:Patches were generated and checked against linux-4.14-rc6 for a subset ofthe use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up caseswhere non-standard license headers were used, and references to licensehad to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied toa file was done in a spreadsheet of side by side results from of theoutput of two independent scanners (ScanCode & Windriver) producing SPDXtag:value files created by Philippe Ombredanne. Philippe prepared thebase worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 filesassessed. Kate Stewart did a file by file comparison of the scannerresults in the spreadsheet to determine which SPDX license identifier(s)to be applied to the file. She confirmed any determination that was notimmediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.In total, over 70 hours of logged manual review was done on thespreadsheet to determine the SPDX license identifiers to apply to thesource files by Kate, Philippe, Thomas and, in some cases, confirmationby lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base fromFOSSology, and compared selected files where the other two scannersdisagreed against that SPDX file, to see if there was new insights. TheWindriver scanner is based on an older version of FOSSology in part, sothey are related.Thomas did random spot checks in about 500 files from the spreadsheetsfor the uapi headers and agreed with SPDX license identifier in thefiles he inspected. For the non-uapi files Thomas did random spot checksin about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to havecopy/paste license identifier errors, and have been fixed to reflect thecorrect identifier.Additionally Philippe spent 10 hours this week doing a detailed manualinspection and review of the 12,461 patched files from the initial patchversion early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. Thisworksheet was then exported into 3 different .csv files for thedifferent types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script toparse the csv files and add the proper SPDX tag to the file, in theformat that the file expected. This script was further refined by Gregbased on the output to detect more types of files automatically and todistinguish between header and source .c files (which need differentcomment types.) Finally Greg ran the script using the .csv files togenerate the patches.Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/arch/x86/events/intel/Makefile

c39a0e2c - x86/perf/cqm: Wipe out perf based cqm

Tue, 25 Jul 2017 21:14:20 +0000

x86/perf/cqm: Wipe out perf based cqm'perf cqm' never worked due to the incompatibility between perfinfrastructure and cqm hardware support. The hardware uses RMIDs totrack the llc occupancy of tasks and these RMIDs are per package. Thismakes monitoring a hierarchy like cgroup along with monitoring of tasksseparately difficult and several patches sent to lkml to fix them wereNACKed. Further more, the following issues in the current perf cqm makeit almost unusable: 1. No support to monitor the same group of tasks for which we do allocation using resctrl. 2. It gives random and inaccurate data (mostly 0s) once we run out of RMIDs due to issues in Recycling. 3. Recycling results in inaccuracy of data because we cannot guarantee that the RMID was stolen from a task when it was not pulling data into cache or even when it pulled the least data. Also for monitoring llc_occupancy, if we stop using an RMID_x and then start using an RMID_y after we reclaim an RMID from an other event, we miss accounting all the occupancy that was tagged to RMID_x at a later perf_count. 2. Recycling code makes the monitoring code complex including scheduling because the event can lose RMID any time. Since MBM counters count bandwidth for a period of time by taking snap shot of total bytes at two different times, recycling complicates the way we count MBM in a hierarchy. Also we need a spin lock while we do the processing to account for MBM counter overflow. We also currently use a spin lock in scheduling to prevent the RMID from being taken away. 4. Lack of support when we run different kind of event like task, system-wide and cgroup events together. Data mostly prints 0s. This is also because we can have only one RMID tied to a cpu as defined by the cqm hardware but a perf can at the same time tie multiple events during one sched_in. 5. No support of monitoring a group of tasks. There is partial support for cgroup but it does not work once there is a hierarchy of cgroups or if we want to monitor a task in a cgroup and the cgroup itself. 6. No support for monitoring tasks for the lifetime without perf overhead. 7. It reported the aggregate cache occupancy or memory bandwidth over all sockets. But most cloud and VMM based use cases want to know the individual per-socket usage.Signed-off-by: Vikas Shivappa Signed-off-by: Thomas Gleixner Cc: ravi.v.shankar@intel.comCc: tony.luck@intel.comCc: fenghua.yu@intel.comCc: peterz@infradead.orgCc: eranian@google.comCc: vikas.shivappa@intel.comCc: ak@linux.intel.comCc: davidcc@google.comCc: reinette.chatre@intel.comLink: http://lkml.kernel.org/r/1501017287-28083-2-git-send-email-vikas.shivappa@linux.intel.com List of files: /linux-6.15/arch/x86/events/intel/Makefile

175a20c1 - x86/perf/intel/rapl: Fix module name collision with powercap intel-rapl

Thu, 23 Jun 2016 15:06:49 +0000

x86/perf/intel/rapl: Fix module name collision with powercap intel-raplSince commit 4b6e2571bf00 the rapl perf module calls itself intel-rapl. Thatname was already in use by the rapl powercap driver, which now fails to loadif the perf module is loaded. Fix the problem by renaming the perf module tointel-rapl-perf, so that both modules can coexist.Fixes: 4b6e2571bf00 ("x86/perf/intel/rapl: Make the Intel RAPL PMU driver modular")Signed-off-by: Ville Syrjälä Cc: Vince Weaver Cc: Alexander Shishkin Cc: Kan Liang Cc: Stephane Eranian Cc: Arnaldo Carvalho de Melo Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Jiri Olsa Link: http://lkml.kernel.org/r/1466694409-3620-1-git-send-email-ville.syrjala@linux.intel.comSigned-off-by: Thomas Gleixner List of files: /linux-6.15/arch/x86/events/intel/Makefile

c7afba32 - x86/perf/intel/cstate: Modularize driver

Sun, 20 Mar 2016 18:59:04 +0000

x86/perf/intel/cstate: Modularize driverAdd the exit function and allow the driver to be built as a module.Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Jiri Olsa Cc: Kan Liang Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Vince Weaver Link: http://lkml.kernel.org/r/20160320185623.658869675@linutronix.deSigned-off-by: Ingo Molnar List of files: /linux-6.15/arch/x86/events/intel/Makefile

4b6e2571 - x86/perf/intel/rapl: Make the Intel RAPL PMU driver modular

Sat, 19 Mar 2016 07:20:50 +0000

x86/perf/intel/rapl: Make the Intel RAPL PMU driver modularBy default, the RAPL driver will be built into the kernel. If it isconfigured as a module, the supported CPU model can be auto loaded.Also clean up the code of rapl_pmu_init().Based-on-a-patch-by: Thomas Gleixner Signed-off-by: Kan Liang Signed-off-by: Thomas Gleixner Reviewed-by: Thomas Gleixner Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Vince Weaver Link: http://lkml.kernel.org/r/1458372050-2420-2-git-send-email-kan.liang@intel.comSigned-off-by: Ingo Molnar List of files: /linux-6.15/arch/x86/events/intel/Makefile

e633c65a - x86/perf/intel/uncore: Make the Intel uncore PMU driver modular

Sun, 20 Mar 2016 08:33:36 +0000

x86/perf/intel/uncore: Make the Intel uncore PMU driver modularBy default, the uncore driver will be built into the kernel. If it isconfigured as a module, the supported CPU model can be auto loaded.This patch also cleans up the code of uncore_cpu_init() anduncore_pci_init().Based-on-a-patch-by: Thomas Gleixner Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Thomas Gleixner Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Vince Weaver Link: http://lkml.kernel.org/r/1458462817-2475-1-git-send-email-kan.liang@intel.comSigned-off-by: Ingo Molnar List of files: /linux-6.15/arch/x86/events/intel/Makefile