1. 29 6月, 2022 1 次提交
  2. 11 6月, 2022 1 次提交
  3. 08 6月, 2022 1 次提交
  4. 07 6月, 2022 2 次提交
  5. 04 6月, 2022 17 次提交
  6. 03 6月, 2022 3 次提交
  7. 02 6月, 2022 1 次提交
  8. 01 6月, 2022 2 次提交
  9. 31 5月, 2022 1 次提交
  10. 28 5月, 2022 10 次提交
    • M
      selftests: memcg: factor out common parts of memory.{low,min} tests · f079a020
      Michal Koutný 提交于
      The memory protection test setup and runtime is almost equal for
      memory.low and memory.min cases.
      
      It makes modification of the common parts prone to mistakes, since the
      protections are similar not only in setup but also in principle, factor
      the common part out.
      
      Past exceptions between the tests:
      - missing memory.min is fine (kept),
      - test_memcg_low protected orphaned pagecache (adapted like
        test_memcg_min and we keep the processes of protected memory running).
      
      The evaluation in two tests is different (OOM of allocator vs low events
      of protégés), this is kept different.
      
      Link: https://lkml.kernel.org/r/20220518161859.21565-6-mkoutny@suse.comSigned-off-by: NMichal Koutný <mkoutny@suse.com>
      Acked-by: NRoman Gushchin <roman.gushchin@linux.dev>
      CC: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Shakeel Butt <shakeelb@google.com>
      Cc: Richard Palethorpe <rpalethorpe@suse.de>
      Cc: David Vernet <void@manifault.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      f079a020
    • M
      selftests: memcg: remove protection from top level memcg · 6a359190
      Michal Koutný 提交于
      The reclaim is triggered by memory limit in a subtree, therefore the
      testcase does not need configured protection against external reclaim.
      
      Also, correct respective comments.
      
      Link: https://lkml.kernel.org/r/20220518161859.21565-5-mkoutny@suse.comSigned-off-by: NMichal Koutný <mkoutny@suse.com>
      Acked-by: NRoman Gushchin <roman.gushchin@linux.dev>
      Cc: David Vernet <void@manifault.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Richard Palethorpe <rpalethorpe@suse.de>
      Cc: Shakeel Butt <shakeelb@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      6a359190
    • M
      selftests: memcg: adjust expected reclaim values of protected cgroups · f10b6e9a
      Michal Koutný 提交于
      The numbers are not easy to derive in a closed form (certainly mere
      protections ratios do not apply), therefore use a simulation to obtain
      expected numbers.
      
      Link: https://lkml.kernel.org/r/20220518161859.21565-4-mkoutny@suse.comSigned-off-by: NMichal Koutný <mkoutny@suse.com>
      Acked-by: NRoman Gushchin <roman.gushchin@linux.dev>
      Cc: David Vernet <void@manifault.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Richard Palethorpe <rpalethorpe@suse.de>
      Cc: Shakeel Butt <shakeelb@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      f10b6e9a
    • M
      selftests: memcg: expect no low events in unprotected sibling · 1d09069f
      Michal Koutný 提交于
      This is effectively a revert of commit cdc69458 ("cgroup: account for
      memory_recursiveprot in test_memcg_low()").  The case test_memcg_low will
      fail with memory_recursiveprot until resolved in reclaim code.
      
      However, this patch preserves the existing helpers and variables for later
      uses.
      
      Link: https://lkml.kernel.org/r/20220518161859.21565-3-mkoutny@suse.comSigned-off-by: NMichal Koutný <mkoutny@suse.com>
      Reviewed-by: NDavid Vernet <void@manifault.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Richard Palethorpe <rpalethorpe@suse.de>
      Cc: Roman Gushchin <roman.gushchin@linux.dev>
      Cc: Shakeel Butt <shakeelb@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      1d09069f
    • M
      selftests: memcg: fix compilation · ff3b72a5
      Michal Koutný 提交于
      Patch series "memcontrol selftests fixups", v2.
      
      Flushing the patches to make memcontrol selftests check the events
      behavior we had consensus about (test_memcg_low fails).
      
      (test_memcg_reclaim, test_memcg_swap_max fail for me now but it's present
      even before the refactoring.)
      
      The two bigger changes are:
      - adjustment of the protected values to make tests succeed with the given
        tolerance,
      - both test_memcg_low and test_memcg_min check protection of memory in
        populated cgroups (actually as per Documentation/admin-guide/cgroup-v2.rst
        memory.min should not apply to empty cgroups, which is not the case
        currently. Therefore I unified tests with the populated case in order to to
        bring more broken tests).
      
      
      This patch (of 5):
      
      This fixes mis-applied changes from commit 72b1e03a ("cgroup: account
      for memory_localevents in test_memcg_oom_group_leaf_events()").
      
      Link: https://lkml.kernel.org/r/20220518161859.21565-1-mkoutny@suse.com
      Link: https://lkml.kernel.org/r/20220518161859.21565-2-mkoutny@suse.comSigned-off-by: NMichal Koutný <mkoutny@suse.com>
      Reviewed-by: NDavid Vernet <void@manifault.com>
      Acked-by: NRoman Gushchin <roman.gushchin@linux.dev>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Richard Palethorpe <rpalethorpe@suse.de>
      Cc: Shakeel Butt <shakeelb@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      ff3b72a5
    • A
      tools arch x86: Sync the msr-index.h copy with the kernel sources · 9dde6cad
      Arnaldo Carvalho de Melo 提交于
      To pick up the changes in:
      
        db1af129 ("x86/msr-index: Define INTEGRITY_CAPABILITIES MSR")
        089be16d ("x86/msr: Add PerfCntrGlobal* registers")
        f52ba931 ("tools/power turbostat: Add Power Limit4 support")
      
      Addressing these tools/perf build warnings:
      
          diff -u tools/arch/x86/include/asm/msr-index.h arch/x86/include/asm/msr-index.h
          Warning: Kernel ABI header at 'tools/arch/x86/include/asm/msr-index.h' differs from latest version at 'arch/x86/include/asm/msr-index.h'
      
      That makes the beautification scripts to pick some new entries:
      
        $ tools/perf/trace/beauty/tracepoints/x86_msr.sh > before
        $ cp arch/x86/include/asm/msr-index.h tools/arch/x86/include/asm/msr-index.h
        $ tools/perf/trace/beauty/tracepoints/x86_msr.sh > after
        $ diff -u before after
        --- before	2022-05-26 12:50:01.228612839 -0300
        +++ after	2022-05-26 12:50:07.699776166 -0300
        @@ -116,6 +116,7 @@
         	[0x0000026f] = "MTRRfix4K_F8000",
         	[0x00000277] = "IA32_CR_PAT",
         	[0x00000280] = "IA32_MC0_CTL2",
        +	[0x000002d9] = "INTEGRITY_CAPS",
         	[0x000002ff] = "MTRRdefType",
         	[0x00000309] = "CORE_PERF_FIXED_CTR0",
         	[0x0000030a] = "CORE_PERF_FIXED_CTR1",
        @@ -176,6 +177,7 @@
         	[0x00000586] = "IA32_RTIT_ADDR3_A",
         	[0x00000587] = "IA32_RTIT_ADDR3_B",
         	[0x00000600] = "IA32_DS_AREA",
        +	[0x00000601] = "VR_CURRENT_CONFIG",
         	[0x00000606] = "RAPL_POWER_UNIT",
         	[0x0000060a] = "PKGC3_IRTL",
         	[0x0000060b] = "PKGC6_IRTL",
        @@ -260,6 +262,10 @@
         	[0xc0000102 - x86_64_specific_MSRs_offset] = "KERNEL_GS_BASE",
         	[0xc0000103 - x86_64_specific_MSRs_offset] = "TSC_AUX",
         	[0xc0000104 - x86_64_specific_MSRs_offset] = "AMD64_TSC_RATIO",
        +	[0xc000010f - x86_64_specific_MSRs_offset] = "AMD_DBG_EXTN_CFG",
        +	[0xc0000300 - x86_64_specific_MSRs_offset] = "AMD64_PERF_CNTR_GLOBAL_STATUS",
        +	[0xc0000301 - x86_64_specific_MSRs_offset] = "AMD64_PERF_CNTR_GLOBAL_CTL",
        +	[0xc0000302 - x86_64_specific_MSRs_offset] = "AMD64_PERF_CNTR_GLOBAL_STATUS_CLR",
         };
      
         #define x86_AMD_V_KVM_MSRs_offset 0xc0010000
        @@ -318,4 +324,5 @@
         	[0xc00102b4 - x86_AMD_V_KVM_MSRs_offset] = "AMD_CPPC_STATUS",
         	[0xc00102f0 - x86_AMD_V_KVM_MSRs_offset] = "AMD_PPIN_CTL",
         	[0xc00102f1 - x86_AMD_V_KVM_MSRs_offset] = "AMD_PPIN",
        +	[0xc0010300 - x86_AMD_V_KVM_MSRs_offset] = "AMD_SAMP_BR_FROM",
         };
        $
      
      Now one can trace systemwide asking to see backtraces to where those
      MSRs are being read/written, see this example with a previous update:
      
        # perf trace -e msr:*_msr/max-stack=32/ --filter="msr>=IA32_U_CET && msr<=IA32_INT_SSP_TAB"
        ^C#
      
      If we use -v (verbose mode) we can see what it does behind the scenes:
      
        # perf trace -v -e msr:*_msr/max-stack=32/ --filter="msr>=IA32_U_CET && msr<=IA32_INT_SSP_TAB"
        Using CPUID AuthenticAMD-25-21-0
        0x6a0
        0x6a8
        New filter for msr:read_msr: (msr>=0x6a0 && msr<=0x6a8) && (common_pid != 597499 && common_pid != 3313)
        0x6a0
        0x6a8
        New filter for msr:write_msr: (msr>=0x6a0 && msr<=0x6a8) && (common_pid != 597499 && common_pid != 3313)
        mmap size 528384B
        ^C#
      
      Example with a frequent msr:
      
        # perf trace -v -e msr:*_msr/max-stack=32/ --filter="msr==IA32_SPEC_CTRL" --max-events 2
        Using CPUID AuthenticAMD-25-21-0
        0x48
        New filter for msr:read_msr: (msr==0x48) && (common_pid != 2612129 && common_pid != 3841)
        0x48
        New filter for msr:write_msr: (msr==0x48) && (common_pid != 2612129 && common_pid != 3841)
        mmap size 528384B
        Looking at the vmlinux_path (8 entries long)
        symsrc__init: build id mismatch for vmlinux.
        Using /proc/kcore for kernel data
        Using /proc/kallsyms for symbols
           0.000 Timer/2525383 msr:write_msr(msr: IA32_SPEC_CTRL, val: 6)
                                             do_trace_write_msr ([kernel.kallsyms])
                                             do_trace_write_msr ([kernel.kallsyms])
                                             __switch_to_xtra ([kernel.kallsyms])
                                             __switch_to ([kernel.kallsyms])
                                             __schedule ([kernel.kallsyms])
                                             schedule ([kernel.kallsyms])
                                             futex_wait_queue_me ([kernel.kallsyms])
                                             futex_wait ([kernel.kallsyms])
                                             do_futex ([kernel.kallsyms])
                                             __x64_sys_futex ([kernel.kallsyms])
                                             do_syscall_64 ([kernel.kallsyms])
                                             entry_SYSCALL_64_after_hwframe ([kernel.kallsyms])
                                             __futex_abstimed_wait_common64 (/usr/lib64/libpthread-2.33.so)
           0.030 :0/0 msr:write_msr(msr: IA32_SPEC_CTRL, val: 2)
                                             do_trace_write_msr ([kernel.kallsyms])
                                             do_trace_write_msr ([kernel.kallsyms])
                                             __switch_to_xtra ([kernel.kallsyms])
                                             __switch_to ([kernel.kallsyms])
                                             __schedule ([kernel.kallsyms])
                                             schedule_idle ([kernel.kallsyms])
                                             do_idle ([kernel.kallsyms])
                                             cpu_startup_entry ([kernel.kallsyms])
                                             secondary_startup_64_no_verify ([kernel.kallsyms])
        #
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sandipan Das <sandipan.das@amd.com>
      Cc: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Link: https://lore.kernel.org/lkml/Yo+i%252Fj5+UtE9dcix@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9dde6cad
    • L
      perf scripts python: Support Arm CoreSight trace data disassembly · 12fdd6c0
      Leo Yan 提交于
      This commit adds python script to parse CoreSight tracing event and
      print out source line and disassembly, it generates readable program
      execution flow for easier humans inspecting.
      
      The script receives CoreSight tracing packet with below format:
      
                      +------------+------------+------------+
        packet(n):    |    addr    |    ip      |    cpu     |
                      +------------+------------+------------+
        packet(n+1):  |    addr    |    ip      |    cpu     |
                      +------------+------------+------------+
      
      packet::addr presents the start address of the coming branch sample, and
      packet::ip is the last address of the branch smple.  Therefore, a code
      section between branches starts from packet(n)::addr and it stops at
      packet(n+1)::ip.  As results we combines the two continuous packets to
      generate the address range for instructions:
      
        [ sample(n)::addr .. sample(n+1)::ip ]
      
      The script supports both objdump or llvm-objdump for disassembly with
      specifying option '-d'.  If doesn't specify option '-d', the script
      simply outputs source lines and symbols.
      
      Below shows usages with llvm-objdump or objdump to output disassembly.
      
        # perf script -s scripts/python/arm-cs-trace-disasm.py -- -d llvm-objdump-11 -k ./vmlinux
        ARM CoreSight Trace Data Assembler Dump
        	ffff800008eb3198 <etm4_enable_hw>:
        	ffff800008eb3310: c0 38 00 35  	cbnz	w0, 0xffff800008eb3a28 <etm4_enable_hw+0x890>
        	ffff800008eb3314: 9f 3f 03 d5  	dsb	sy
        	ffff800008eb3318: df 3f 03 d5  	isb
        	ffff800008eb331c: f5 5b 42 a9  	ldp	x21, x22, [sp, #32]
        	ffff800008eb3320: fb 73 45 a9  	ldp	x27, x28, [sp, #80]
        	ffff800008eb3324: e0 82 40 39  	ldrb	w0, [x23, #32]
        	ffff800008eb3328: 60 00 00 34  	cbz	w0, 0xffff800008eb3334 <etm4_enable_hw+0x19c>
        	ffff800008eb332c: e0 03 19 aa  	mov	x0, x25
        	ffff800008eb3330: 8c fe ff 97  	bl	0xffff800008eb2d60 <etm4_cs_lock.isra.0.part.0>
                    main  6728/6728  [0004]         0.000000000  etm4_enable_hw+0x198                    [kernel.kallsyms]
        	ffff800008eb2d60 <etm4_cs_lock.isra.0.part.0>:
        	ffff800008eb2d60: 1f 20 03 d5  	nop
        	ffff800008eb2d64: 1f 20 03 d5  	nop
        	ffff800008eb2d68: 3f 23 03 d5  	hint	#25
        	ffff800008eb2d6c: 00 00 40 f9  	ldr	x0, [x0]
        	ffff800008eb2d70: 9f 3f 03 d5  	dsb	sy
        	ffff800008eb2d74: 00 c0 3e 91  	add	x0, x0, #4016
        	ffff800008eb2d78: 1f 00 00 b9  	str	wzr, [x0]
        	ffff800008eb2d7c: bf 23 03 d5  	hint	#29
        	ffff800008eb2d80: c0 03 5f d6  	ret
                    main  6728/6728  [0004]         0.000000000  etm4_cs_lock.isra.0.part.0+0x20
      
        # perf script -s scripts/python/arm-cs-trace-disasm.py -- -d objdump -k ./vmlinux
        ARM CoreSight Trace Data Assembler Dump
        	ffff800008eb3310 <etm4_enable_hw+0x178>:
        	ffff800008eb3310:	350038c0 	cbnz	w0, ffff800008eb3a28 <etm4_enable_hw+0x890>
        	ffff800008eb3314:	d5033f9f 	dsb	sy
        	ffff800008eb3318:	d5033fdf 	isb
        	ffff800008eb331c:	a9425bf5 	ldp	x21, x22, [sp, #32]
        	ffff800008eb3320:	a94573fb 	ldp	x27, x28, [sp, #80]
        	ffff800008eb3324:	394082e0 	ldrb	w0, [x23, #32]
        	ffff800008eb3328:	34000060 	cbz	w0, ffff800008eb3334 <etm4_enable_hw+0x19c>
        	ffff800008eb332c:	aa1903e0 	mov	x0, x25
        	ffff800008eb3330:	97fffe8c 	bl	ffff800008eb2d60 <etm4_cs_lock.isra.0.part.0>
                    main  6728/6728  [0004]         0.000000000  etm4_enable_hw+0x198                    [kernel.kallsyms]
        	ffff800008eb2d60 <etm4_cs_lock.isra.0.part.0>:
        	ffff800008eb2d60:	d503201f 	nop
        	ffff800008eb2d64:	d503201f 	nop
        	ffff800008eb2d68:	d503233f 	paciasp
        	ffff800008eb2d6c:	f9400000 	ldr	x0, [x0]
        	ffff800008eb2d70:	d5033f9f 	dsb	sy
        	ffff800008eb2d74:	913ec000 	add	x0, x0, #0xfb0
        	ffff800008eb2d78:	b900001f 	str	wzr, [x0]
        	ffff800008eb2d7c:	d50323bf 	autiasp
        	ffff800008eb2d80:	d65f03c0 	ret
                    main  6728/6728  [0004]         0.000000000  etm4_cs_lock.isra.0.part.0+0x20
      Signed-off-by: NLeo Yan <leo.yan@linaro.org>
      Co-authored-by: NAl Grant <al.grant@arm.com>
      Co-authored-by: NMathieu Poirier <mathieu.poirier@linaro.org>
      Co-authored-by: NTor Jeremiassen <tor@ti.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Eelco Chaudron <echaudro@redhat.com>
      Cc: German Gomez <german.gomez@arm.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: James Clark <james.clark@arm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephen Brennan <stephen.s.brennan@oracle.com>
      Cc: Tanmay Jagdale <tanmay@marvell.com>
      Cc: coresight@lists.linaro.org
      Cc: zengshun . wu <zengshun.wu@outlook.com>
      Link: https://lore.kernel.org/r/20220521130446.4163597-3-leo.yan@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      12fdd6c0
    • L
      perf scripting python: Expose dso and map information · c4f46223
      Leo Yan 提交于
      This change adds dso build_id and corresponding map's start and end
      address.  The info of dso build_id can be used to find dso file path,
      and we can validate if a branch address falls into the range of map's
      start and end addresses.
      
      In addition, the map's start address can be used as an offset for
      disassembly.
      Signed-off-by: NLeo Yan <leo.yan@linaro.org>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Al Grant <al.grant@arm.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Eelco Chaudron <echaudro@redhat.com>
      Cc: German Gomez <german.gomez@arm.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: James Clark <james.clark@arm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephen Brennan <stephen.s.brennan@oracle.com>
      Cc: Tanmay Jagdale <tanmay@marvell.com>
      Cc: coresight@lists.linaro.org
      Cc: zengshun . wu <zengshun.wu@outlook.com>
      Link: https://lore.kernel.org/r/20220521130446.4163597-2-leo.yan@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c4f46223
    • Z
      perf jevents: Fix event syntax error caused by ExtSel · f4df0dbb
      Zhengjun Xing 提交于
      In the origin code, when "ExtSel" is 1, the eventcode will change to
      "eventcode |= 1 << 21”. For event “UNC_Q_RxL_CREDITS_CONSUMED_VN0.DRS",
      its "ExtSel" is "1", its eventcode will change from 0x1E to 0x20001E,
      but in fact the eventcode should <=0x1FF, so this will cause the parse
      fail:
      
        # perf stat -e "UNC_Q_RxL_CREDITS_CONSUMED_VN0.DRS" -a sleep 0.1
        event syntax error: '.._RxL_CREDITS_CONSUMED_VN0.DRS'
                                          \___ value too big for format, maximum is 511
      
      On the perf kernel side, the kernel assumes the valid bits are continuous.
      It will adjust the 0x100 (bit 8 for perf tool) to bit 21 in HW.
      
      DEFINE_UNCORE_FORMAT_ATTR(event_ext, event, "config:0-7,21");
      
      So the perf tool follows the kernel side and just set bit8 other than bit21.
      
      Fixes: fedb2b51 ("perf jevents: Add support for parsing uncore json files")
      Reviewed-by: NKan Liang <kan.liang@linux.intel.com>
      Signed-off-by: NXing Zhengjun <zhengjun.xing@linux.intel.com>
      Acked-by: NIan Rogers <irogers@google.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: https://lore.kernel.org/r/20220525140410.1706851-1-zhengjun.xing@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f4df0dbb
    • J
      perf tools arm64: Add support for VG register · 2be00431
      James Clark 提交于
      Add the name of the VG register so it can be used in --user-regs
      
      The event will fail to open if the register is requested but not
      available so only add it to the mask if the kernel supports sve and also
      if it supports that specific register.
      
      Committer notes:
      
      Add conditional definition of HWCAP_SVE, as suggested by Leo Yan, to
      build on older systems where this is not available in the system
      headers.
      Reviewed-by: NLeo Yan <leo.yan@linaro.org>
      Signed-off-by: NJames Clark <james.clark@arm.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: German Gomez <german.gomez@arm.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: John Garry <john.garry@huawei.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Mike Leach <mike.leach@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Will Deacon <will@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: https://lore.kernel.org/r/20220525154114.718321-6-james.clark@arm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2be00431
  11. 27 5月, 2022 1 次提交