Re: [PATCH] x86/speculation/l1tf: Exempt zeroed PTEs from XOR conversion

which walks the PTEs to check the PFNs. > prot_none_pte_entry() gets the bogus PFN from pte_pfn() and returns > -EACCES because it thinks mprotect() is trying to adjust a high MMIO > address. Looks good to me. You're right that case was missed. Reviewed-by: Andi Kleen I think Thomas is still on vacation, copying Linus. -Andi

[PATCH] x86/speculation/l1tf: Add assembly guard for xtensa/ia64

From: Andi Kleen The stable backport of the x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings patch for 4.4 and 4.9 put new C code for !__HAVE_ARCH_PFN_MODIFY_ALLOWED code outside the assembler ifdef. This breaks the xtensa and ia64 build as reported by 0day which

[PATCH] x86/speculation/l1tf: Add assembly guard for xtensa/ia64

From: Andi Kleen The stable backport of the x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings patch for 4.4 and 4.9 put new C code for !__HAVE_ARCH_PFN_MODIFY_ALLOWED code outside the assembler ifdef. This breaks the xtensa and ia64 build as reported by 0day which

Re: [RFC] perf/x86/intel: Export mem events only if there's PEBs support

cause we can't access LDLAT msr > > however that's not so easy/straight forward to check, > so I thought we could use check on PEBs instead, which > needs to be there for mem events as well and seems to > be enough to check > > thoughts? thanks, > jirka Acked-by: Andi Kleen -Andi

Re: [RFC] perf/x86/intel: Export mem events only if there's PEBs support

cause we can't access LDLAT msr > > however that's not so easy/straight forward to check, > so I thought we could use check on PEBs instead, which > needs to be there for mem events as well and seems to > be enough to check > > thoughts? thanks, > jirka Acked-by: Andi Kleen -Andi

Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake

> Which simply does not work. Look at Goldmont Fam 6 Model 5C. The SoCs > with that Fam/Model combination are: > > - Apollo Lake > - Broxton (has two platforms: Morganfield and Willowtrail) Right pick one. The others are the same for software purposes and can be handled in the same way. > >

Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake

> Which simply does not work. Look at Goldmont Fam 6 Model 5C. The SoCs > with that Fam/Model combination are: > > - Apollo Lake > - Broxton (has two platforms: Morganfield and Willowtrail) Right pick one. The others are the same for software purposes and can be handled in the same way. > >

Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake

On Tue, Aug 07, 2018 at 07:48:51PM +0200, Peter Zijlstra wrote: > On Tue, Aug 07, 2018 at 10:35:42AM -0700, Dave Hansen wrote: > > On 08/07/2018 10:17 AM, kan.li...@linux.intel.com wrote: > > > Denverton and Gemini Lake are platform names and should not be used for > > > Processor Family stuff.

Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake

On Tue, Aug 07, 2018 at 07:48:51PM +0200, Peter Zijlstra wrote: > On Tue, Aug 07, 2018 at 10:35:42AM -0700, Dave Hansen wrote: > > On 08/07/2018 10:17 AM, kan.li...@linux.intel.com wrote: > > > Denverton and Gemini Lake are platform names and should not be used for > > > Processor Family stuff.

Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake

On Tue, Aug 07, 2018 at 10:17:27AM -0700, kan.li...@linux.intel.com wrote: > From: Kan Liang > > Denverton and Gemini Lake are platform names and should not be used for > Processor Family stuff. The microarchitecture codename should be used. > > DENVERTON is Goldmont server SoC. Rename

Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake

On Tue, Aug 07, 2018 at 10:17:27AM -0700, kan.li...@linux.intel.com wrote: > From: Kan Liang > > Denverton and Gemini Lake are platform names and should not be used for > Processor Family stuff. The microarchitecture codename should be used. > > DENVERTON is Goldmont server SoC. Rename

Re: [PATCH 2/3] x86, perf: Add a separate Arch Perfmon v4 PMI handler

On Mon, Aug 06, 2018 at 08:35:15PM +0200, Peter Zijlstra wrote: > > +static bool disable_counter_freezing; > > +module_param(disable_counter_freezing, bool, 0444); > > +MODULE_PARM_DESC(disable_counter_freezing, "Disable counter freezing > > feature." > > + "The PMI handler will fall

Re: [PATCH 2/3] x86, perf: Add a separate Arch Perfmon v4 PMI handler

On Mon, Aug 06, 2018 at 08:35:15PM +0200, Peter Zijlstra wrote: > > +static bool disable_counter_freezing; > > +module_param(disable_counter_freezing, bool, 0444); > > +MODULE_PARM_DESC(disable_counter_freezing, "Disable counter freezing > > feature." > > + "The PMI handler will fall

Re: [PATCH 2/4] trace: avoid calling cc-option -mrecord-mcount for every Makefile

ile doing that also add -mrecord-mcount to CC_FLAGS_FTRACE (if gcc > actually supports it). > > Signed-off-by: Vasily Gorbik Acked-by: Andi Kleen -Andi

Re: [PATCH 2/4] trace: avoid calling cc-option -mrecord-mcount for every Makefile

ile doing that also add -mrecord-mcount to CC_FLAGS_FTRACE (if gcc > actually supports it). > > Signed-off-by: Vasily Gorbik Acked-by: Andi Kleen -Andi

Re: [PATCH 3/7] x86/mm/init: pass unconverted symbol addresses to free_init_pages()

> [ Goes around and rummages ] > > Oh, never mind, looking around reminded me why: we want to map the > kernel text in the top 31 bits, so that we can use the faster > -mcmodel=kernel because all symbols fit in sign-extended 32 bits. > > Maybe there was some other reason too, but I think that's

Re: [PATCH 3/7] x86/mm/init: pass unconverted symbol addresses to free_init_pages()

> [ Goes around and rummages ] > > Oh, never mind, looking around reminded me why: we want to map the > kernel text in the top 31 bits, so that we can use the faster > -mcmodel=kernel because all symbols fit in sign-extended 32 bits. > > Maybe there was some other reason too, but I think that's

Re: Perf JSON events mismatch with Intel SDM

>The semantic difference being, as far as I can tell, that the "GT" >counters do not sample randomly, but will rather offer a precise count of >loads meeting the stated condition.  It's all the same underlying hardware event. The only difference is what threshold is used for

Re: Perf JSON events mismatch with Intel SDM

>The semantic difference being, as far as I can tell, that the "GT" >counters do not sample randomly, but will rather offer a precise count of >loads meeting the stated condition.  It's all the same underlying hardware event. The only difference is what threshold is used for

Re: Perf JSON events mismatch with Intel SDM

> now need to dive in deep into the actual implementation. Simple question: is > this a bug? These are derived events from MEM_TRANS_RETIRED.LOAD_LATENCY, which is in the SDM. It's not a bug. In general the event lists used by perf are newer versions than what is in the SDM. -Andi

Re: Perf JSON events mismatch with Intel SDM

> now need to dive in deep into the actual implementation. Simple question: is > this a bug? These are derived events from MEM_TRANS_RETIRED.LOAD_LATENCY, which is in the SDM. It's not a bug. In general the event lists used by perf are newer versions than what is in the SDM. -Andi

Re: [bug] kpti, perf_event, bts: sporadic truncated trace

"Metzger, Markus T" writes: Adding Dave Hansen > Hello, > > Starting with 4.15 I noticed that BTS is sporadically missing the tail > of the trace in the perf_event data buffer. It shows as > > [decode error (1): instruction overflow] > > in GDB. Chances to see this are higher the longer

Re: [bug] kpti, perf_event, bts: sporadic truncated trace

"Metzger, Markus T" writes: Adding Dave Hansen > Hello, > > Starting with 4.15 I noticed that BTS is sporadically missing the tail > of the trace in the perf_event data buffer. It shows as > > [decode error (1): instruction overflow] > > in GDB. Chances to see this are higher the longer

Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"

> At least we need to make user aware about risk of setting custom flags. There are valid use cases to override the flags. I use it sometimes too, and know some other people do to. But you need to know what you're doing. Perhaps a warning during build would be reasonable. So if you ask for a

Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"

> At least we need to make user aware about risk of setting custom flags. There are valid use cases to override the flags. I use it sometimes too, and know some other people do to. But you need to know what you're doing. Perhaps a warning during build would be reasonable. So if you ask for a

Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"

On Tue, Jul 03, 2018 at 11:26:09PM +0300, Kirill A. Shutemov wrote: > On Tue, Jul 03, 2018 at 11:03:07AM -0700, Andi Kleen wrote: > > On Tue, Jul 03, 2018 at 05:21:50PM +0300, Kirill A. Shutemov wrote: > > > On Tue, Jul 03, 2018 at 03:44:03PM +0300, Kirill A. Shutemov wrote: >

Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"

On Tue, Jul 03, 2018 at 11:26:09PM +0300, Kirill A. Shutemov wrote: > On Tue, Jul 03, 2018 at 11:03:07AM -0700, Andi Kleen wrote: > > On Tue, Jul 03, 2018 at 05:21:50PM +0300, Kirill A. Shutemov wrote: > > > On Tue, Jul 03, 2018 at 03:44:03PM +0300, Kirill A. Shutemov wrote: >

Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"

On Tue, Jul 03, 2018 at 05:21:50PM +0300, Kirill A. Shutemov wrote: > On Tue, Jul 03, 2018 at 03:44:03PM +0300, Kirill A. Shutemov wrote: > > On Tue, Jul 03, 2018 at 01:24:49PM +0200, Gabriel C wrote: > > > 2018-07-01 23:32 GMT+02:00 Benjamin Gilbert : > > > > On Sun, Jul 01, 2018 at 05:15:59PM

Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"

On Tue, Jul 03, 2018 at 05:21:50PM +0300, Kirill A. Shutemov wrote: > On Tue, Jul 03, 2018 at 03:44:03PM +0300, Kirill A. Shutemov wrote: > > On Tue, Jul 03, 2018 at 01:24:49PM +0200, Gabriel C wrote: > > > 2018-07-01 23:32 GMT+02:00 Benjamin Gilbert : > > > > On Sun, Jul 01, 2018 at 05:15:59PM

Re: [RFC PATCH for 4.18] rseq: use __u64 for rseq_cs fields, validate user inputs

> > So I think you're good... But yes, you raise an interresting point. So it sounds like architectures that don't have an instruction atomic u64 *_user need to disable interrupts during the access, and somehow handle that case when a page fault happens? -Andi

Re: [RFC PATCH for 4.18] rseq: use __u64 for rseq_cs fields, validate user inputs

> > So I think you're good... But yes, you raise an interresting point. So it sounds like architectures that don't have an instruction atomic u64 *_user need to disable interrupts during the access, and somehow handle that case when a page fault happens? -Andi

Re: [PATCH 4/4 v3] perf stat: Add transaction flag (-T) support for s390

; > > + if (match_metric(pe->metric_group, metric) || > > + match_metric(pe->metric_name, metric)) Why both the group and the metric? I would just match the metric_name Otherwise it's impossible to have a group called "transaction" With that fixed it's ok for me. Acked-by: Andi Kleen -Andi

Re: [PATCH 4/4 v3] perf stat: Add transaction flag (-T) support for s390

; > > + if (match_metric(pe->metric_group, metric) || > > + match_metric(pe->metric_name, metric)) Why both the group and the metric? I would just match the metric_name Otherwise it's impossible to have a group called "transaction" With that fixed it's ok for me. Acked-by: Andi Kleen -Andi

Re: [PATCH 4/4] perf stat: Add transaction flag (-T) support for s390

> > > > You may need to add support for wildcard pmus to it. > > > > -Andi > > > > Currently only one PMU on s390 does support transactions, its the PMU with > counters > named cpum_cf. Right, but you don't want to hard code that pmu into builtin-stat. -Andi

Re: [PATCH 4/4] perf stat: Add transaction flag (-T) support for s390

> > > > You may need to add support for wildcard pmus to it. > > > > -Andi > > > > Currently only one PMU on s390 does support transactions, its the PMU with > counters > named cpum_cf. Right, but you don't want to hard code that pmu into builtin-stat. -Andi

Re: [PATCH 4/4] perf stat: Add transaction flag (-T) support for s390

Thomas Richter writes: > > + /* Handle -T as -M transaction. Once platform specific metrics > + * support has been added to the json files, all archiectures > + * will use this approach. > + */ > + if (!strcmp(perf_env__arch(NULL),

Re: [PATCH 4/4] perf stat: Add transaction flag (-T) support for s390

Thomas Richter writes: > > + /* Handle -T as -M transaction. Once platform specific metrics > + * support has been added to the json files, all archiectures > + * will use this approach. > + */ > + if (!strcmp(perf_env__arch(NULL),

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

> In particular 1) means that any extra instructions executed/not executed > will cause a replay divergence (in practice rr uses retired conditional > branches rather than instructions, because the instruction counter is > not accurate, while the branch one is). This alone causes a problem > for

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

> In particular 1) means that any extra instructions executed/not executed > will cause a replay divergence (in practice rr uses retired conditional > branches rather than instructions, because the instruction counter is > not accurate, while the branch one is). This alone causes a problem > for

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

> Unfortunately, that is insufficient. Almost difference in CPU behavior > between the replayer > and the replayee. In particular, the problems for rr here are > 1) xgetbv, which can introduce differing register contents (and if > code branches on this, > potentially differences in control

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

> Unfortunately, that is insufficient. Almost difference in CPU behavior > between the replayer > and the replayee. In particular, the problems for rr here are > 1) xgetbv, which can introduce differing register contents (and if > code branches on this, > potentially differences in control

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

Patch seems pointless if you can already control CPUID, which rr supports. Just disable AVX512 in CPUID. All code using AVX should check cpuid (or will fail anyways). -Andi

Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread

Patch seems pointless if you can already control CPUID, which rr supports. Just disable AVX512 in CPUID. All code using AVX should check cpuid (or will fail anyways). -Andi

Re: [PATCH] trace: fix SKIP_STACK_VALIDATION=1 build

namic ftrace"), > added a mismatched endif. This causes cmd_objtool to get mistakenly > set. > > Relocate endif to balance the newly added -record-mcount check. > > Fixes: 96f60dfa5819 ("trace: Use -mcount-record for dynamic ftrace") > Signed-off-by: Greg Thelen Looks good thanks. Acked-by: Andi Kleen -Andi

Re: [PATCH] trace: fix SKIP_STACK_VALIDATION=1 build

namic ftrace"), > added a mismatched endif. This causes cmd_objtool to get mistakenly > set. > > Relocate endif to balance the newly added -record-mcount check. > > Fixes: 96f60dfa5819 ("trace: Use -mcount-record for dynamic ftrace") > Signed-off-by: Greg Thelen Looks good thanks. Acked-by: Andi Kleen -Andi

Re: [PATCH 09/10] perf/cputime: Don't stop idle tick if there's live cputime event

On Thu, Jun 07, 2018 at 12:15:12AM +0200, Jiri Olsa wrote: > Disable stopping of the idle tick when having live cputime > event. When the tick is disabled, the idle counts are out > of date until next tick/update and perf cputime PMU provides > misleading counts. I really don't like this. This

Re: [PATCH 09/10] perf/cputime: Don't stop idle tick if there's live cputime event

On Thu, Jun 07, 2018 at 12:15:12AM +0200, Jiri Olsa wrote: > Disable stopping of the idle tick when having live cputime > event. When the tick is disabled, the idle counts are out > of date until next tick/update and perf cputime PMU provides > misleading counts. I really don't like this. This

Re: [RFC 00/10] perf: Add cputime events/metrics

> I had some issues with IDLE counter being miscounted due to stopping > of the idle tick. I tried to solve it in this patch (it's part of the > patchset): > perf/cputime: Don't stop idle tick if there's live cputime event > > but I'm pretty sure it's wrong and there's better solution. At

Re: [PATCH 01/10] perf tools: Uniquify the event name if there's no other matched event

On Thu, Jun 07, 2018 at 12:15:04AM +0200, Jiri Olsa wrote: > Currently by default we try to match the user specified PMU > name to all PMU units available and use them to aggregate > all matched PMUs event counts into one 'pattern' event. > > While this is useful for uncore events, it screws up

Re: [PATCH 01/10] perf tools: Uniquify the event name if there's no other matched event

On Thu, Jun 07, 2018 at 12:15:04AM +0200, Jiri Olsa wrote: > Currently by default we try to match the user specified PMU > name to all PMU units available and use them to aggregate > all matched PMUs event counts into one 'pattern' event. > > While this is useful for uncore events, it screws up

Re: [RFC 00/10] perf: Add cputime events/metrics

> I had some issues with IDLE counter being miscounted due to stopping > of the idle tick. I tried to solve it in this patch (it's part of the > patchset): > perf/cputime: Don't stop idle tick if there's live cputime event > > but I'm pretty sure it's wrong and there's better solution. At

Re: [PATCH V3 02/17] kallsyms, x86: Export addresses of syscall trampolines

t; + for (cpu = cpumask_first(cpu_possible_mask), ncpu = 0; > + cpu < num_possible_cpus() && ncpu < symnum; > + cpu = cpumask_next(cpu, cpu_possible_mask), ncpu++) > + ; That is max_t(unsigned, cpumask_last(cpu_possible_mask), symnum) Rest and ot

Re: [PATCH V3 02/17] kallsyms, x86: Export addresses of syscall trampolines

t; + for (cpu = cpumask_first(cpu_possible_mask), ncpu = 0; > + cpu < num_possible_cpus() && ncpu < symnum; > + cpu = cpumask_next(cpu, cpu_possible_mask), ncpu++) > + ; That is max_t(unsigned, cpumask_last(cpu_possible_mask), symnum) Rest and ot

Re: [PATCH v2]: perf record: enable arbitrary event names thru name= modifier

On Thu, May 31, 2018 at 05:08:12PM +0300, Alexey Budankov wrote: > > Enable complex event names containing [.:=,] symbols to be encoded into Perf > trace using name= modifier e.g. like this: > > perf record -e > cpu/name=\'OFFCORE_RESPONSE:request=DEMAND_RFO:response=L3_HIT.SNOOP_HITM\',\ >

Re: [PATCH v2]: perf record: enable arbitrary event names thru name= modifier

On Thu, May 31, 2018 at 05:08:12PM +0300, Alexey Budankov wrote: > > Enable complex event names containing [.:=,] symbols to be encoded into Perf > trace using name= modifier e.g. like this: > > perf record -e > cpu/name=\'OFFCORE_RESPONSE:request=DEMAND_RFO:response=L3_HIT.SNOOP_HITM\',\ >

Re: [PATCH v2 0/3] perf script python: Add more PMU fields

quite a few fields we report now, for example, > LBRs,data source,weight,transaction,iregs,uregs,and etc. > > This patch adds these fields for perf script python. Patches look good to me. Reviewed-by: Andi Kleen -Andi

Re: [PATCH v2 0/3] perf script python: Add more PMU fields

quite a few fields we report now, for example, > LBRs,data source,weight,transaction,iregs,uregs,and etc. > > This patch adds these fields for perf script python. Patches look good to me. Reviewed-by: Andi Kleen -Andi

Re: [PATCH] perf util: Add more PMU fields for perf script python

On Wed, May 30, 2018 at 10:20:45PM +0800, Jin Yao wrote: > When doing pmu sampling and then running a script with > perf script -s script.py, the process_event function gets > dictionary with some fields from the perf ring buffer > (like ip, sym, callchain etc). > > But we miss quite a few fields

Re: [PATCH] perf util: Add more PMU fields for perf script python

On Wed, May 30, 2018 at 10:20:45PM +0800, Jin Yao wrote: > When doing pmu sampling and then running a script with > perf script -s script.py, the process_event function gets > dictionary with some fields from the perf ring buffer > (like ip, sym, callchain etc). > > But we miss quite a few fields

Re: [RFC] perf: Allow fine-grained PMU access control

> IMHO, it is unsafe for CBOX pmu but could IMC, UPI pmus be an exception here? > Because currently perf stat -I from IMC, UPI counters is only allowed when > system wide monitoring is permitted and this prevents joint perf record and > perf stat -I in cluster environments where users usually

Re: [RFC] perf: Allow fine-grained PMU access control

> IMHO, it is unsafe for CBOX pmu but could IMC, UPI pmus be an exception here? > Because currently perf stat -I from IMC, UPI counters is only allowed when > system wide monitoring is permitted and this prevents joint perf record and > perf stat -I in cluster environments where users usually

Re: x86: Fix AMD K6 indirect call check v2

On Mon, May 21, 2018 at 07:13:37AM -0400, tedheadster wrote: > Andi, > I have a K6 regression testing system. I think my K6 is a revision > C, but I probably can get an earlier cpu (with the bug) to test on. > > Do you have any specific tests you would want me to do on the affected cpu? You

Re: x86: Fix AMD K6 indirect call check v2

On Mon, May 21, 2018 at 07:13:37AM -0400, tedheadster wrote: > Andi, > I have a K6 regression testing system. I think my K6 is a revision > C, but I probably can get an earlier cpu (with the bug) to test on. > > Do you have any specific tests you would want me to do on the affected cpu? You

Re: [PATCH v2] perf tools: allow map files to specify DSO

On Mon, May 07, 2018 at 02:30:32PM -0700, Josh Hunt wrote: > On 05/07/2018 11:40 AM, Andi Kleen wrote: > > On Mon, May 07, 2018 at 02:24:16PM -0400, Josh Hunt wrote: > > > Add the ability to specify a DSO in the /tmp/perf-.map file. > > > The DSO should be the first li

Re: [PATCH v2] perf tools: allow map files to specify DSO

On Mon, May 07, 2018 at 02:30:32PM -0700, Josh Hunt wrote: > On 05/07/2018 11:40 AM, Andi Kleen wrote: > > On Mon, May 07, 2018 at 02:24:16PM -0400, Josh Hunt wrote: > > > Add the ability to specify a DSO in the /tmp/perf-.map file. > > > The DSO should be the first li

Re: [PATCH v2] perf tools: allow map files to specify DSO

On Mon, May 07, 2018 at 02:24:16PM -0400, Josh Hunt wrote: > Add the ability to specify a DSO in the /tmp/perf-.map file. > The DSO should be the first line in the file and readable by the > running user. If a valid DSO is found all other contents of the > file will be ignored. This allows things

Re: [PATCH v2] perf tools: allow map files to specify DSO

On Mon, May 07, 2018 at 02:24:16PM -0400, Josh Hunt wrote: > Add the ability to specify a DSO in the /tmp/perf-.map file. > The DSO should be the first line in the file and readable by the > running user. If a valid DSO is found all other contents of the > file will be ignored. This allows things

Re: [PATCH 05/12] perf pmu: Fix pmu events parsing rule

Jiri Olsa writes: Please fix this quickly, PT is currently totally non functional in Linus mainline. -Andi

Re: [PATCH 05/12] perf pmu: Fix pmu events parsing rule

Jiri Olsa writes: Please fix this quickly, PT is currently totally non functional in Linus mainline. -Andi

Re: [PATCH] perf vendor events: fix spelling mistake: "alloacated" -> "allocated"

On Mon, Apr 30, 2018 at 10:52:56AM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Apr 27, 2018 at 07:52:06PM +0100, Colin King escreveu: > > From: Colin Ian King > > > > Trivial fix to spelling mistakes in json text strings > > These files are generated from other

Re: [PATCH] perf vendor events: fix spelling mistake: "alloacated" -> "allocated"

On Mon, Apr 30, 2018 at 10:52:56AM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Apr 27, 2018 at 07:52:06PM +0100, Colin King escreveu: > > From: Colin Ian King > > > > Trivial fix to spelling mistakes in json text strings > > These files are generated from other files, so any future update

Re: [RFC PATCH] perf tools: allow map files to specify DSO

> Pekka, Andi, Stephane, do you guys see any problems with this? Looks ok to me. -Andi > > If this flies, tools/perf/Documentation/jit-interface.txt needs > updating.

Re: [RFC PATCH] perf tools: allow map files to specify DSO

> Pekka, Andi, Stephane, do you guys see any problems with this? Looks ok to me. -Andi > > If this flies, tools/perf/Documentation/jit-interface.txt needs > updating.

Re: [PATCH] perf vendor events intel: Fix double words "are are" in cache.json

On Wed, Apr 25, 2018 at 12:02:49AM +0900, Masanari Iida wrote: > This patch fix double words "are are". These files are auto generated from another source. I don't think it makes much sense to do a lot of editing on the Linux copies. I will pass it on to the owners of the original files. -Andi

Re: [PATCH] perf vendor events intel: Fix double words "are are" in cache.json

On Wed, Apr 25, 2018 at 12:02:49AM +0900, Masanari Iida wrote: > This patch fix double words "are are". These files are auto generated from another source. I don't think it makes much sense to do a lot of editing on the Linux copies. I will pass it on to the owners of the original files. -Andi

[tip:perf/urgent] perf hists browser: Clarify top/report browser help

Commit-ID: 6a02f06edea5a5910c787fd6c49b0552e8080e5d Gitweb: https://git.kernel.org/tip/6a02f06edea5a5910c787fd6c49b0552e8080e5d Author: Andi Kleen <a...@linux.intel.com> AuthorDate: Fri, 6 Apr 2018 13:38:10 -0700 Committer: Arnaldo Carvalho de Melo <a...@redhat.com> CommitD

[tip:perf/urgent] perf hists browser: Clarify top/report browser help

Commit-ID: 6a02f06edea5a5910c787fd6c49b0552e8080e5d Gitweb: https://git.kernel.org/tip/6a02f06edea5a5910c787fd6c49b0552e8080e5d Author: Andi Kleen AuthorDate: Fri, 6 Apr 2018 13:38:10 -0700 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 18 Apr 2018 15:35:49 -0300 perf hists

[tip:perf/urgent] perf record: Remove suggestion to enable APIC

Commit-ID: ccbb6afe0890b09cc828373a9a5fffab40ec85df Gitweb: https://git.kernel.org/tip/ccbb6afe0890b09cc828373a9a5fffab40ec85df Author: Andi Kleen <a...@linux.intel.com> AuthorDate: Fri, 6 Apr 2018 13:38:12 -0700 Committer: Arnaldo Carvalho de Melo <a...@redhat.com> CommitD

[tip:perf/urgent] perf record: Remove suggestion to enable APIC

Commit-ID: ccbb6afe0890b09cc828373a9a5fffab40ec85df Gitweb: https://git.kernel.org/tip/ccbb6afe0890b09cc828373a9a5fffab40ec85df Author: Andi Kleen AuthorDate: Fri, 6 Apr 2018 13:38:12 -0700 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 18 Apr 2018 15:35:50 -0300 perf record

[tip:perf/urgent] perf record: Remove misleading error suggestion

Commit-ID: ec3948451e0ba317e66873b48d6cc51d701d4eb0 Gitweb: https://git.kernel.org/tip/ec3948451e0ba317e66873b48d6cc51d701d4eb0 Author: Andi Kleen <a...@linux.intel.com> AuthorDate: Fri, 6 Apr 2018 13:38:11 -0700 Committer: Arnaldo Carvalho de Melo <a...@redhat.com> CommitD

[tip:perf/urgent] perf record: Remove misleading error suggestion

Commit-ID: ec3948451e0ba317e66873b48d6cc51d701d4eb0 Gitweb: https://git.kernel.org/tip/ec3948451e0ba317e66873b48d6cc51d701d4eb0 Author: Andi Kleen AuthorDate: Fri, 6 Apr 2018 13:38:11 -0700 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 18 Apr 2018 15:35:49 -0300 perf record

[tip:perf/urgent] perf mem: Allow all record/report options

Commit-ID: a7e9eab3dbd35268c16244557a4155a2d9a641c3 Gitweb: https://git.kernel.org/tip/a7e9eab3dbd35268c16244557a4155a2d9a641c3 Author: Andi Kleen <a...@linux.intel.com> AuthorDate: Fri, 6 Apr 2018 13:38:09 -0700 Committer: Arnaldo Carvalho de Melo <a...@redhat.com> CommitD

[tip:perf/urgent] perf mem: Allow all record/report options

Commit-ID: a7e9eab3dbd35268c16244557a4155a2d9a641c3 Gitweb: https://git.kernel.org/tip/a7e9eab3dbd35268c16244557a4155a2d9a641c3 Author: Andi Kleen AuthorDate: Fri, 6 Apr 2018 13:38:09 -0700 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 18 Apr 2018 15:35:48 -0300 perf mem: Allow

Re: [PATCH 03/35] x86/entry/32: Load task stack from x86_tss.sp1 in SYSENTER handler

On Wed, Apr 18, 2018 at 05:02:02PM -0700, Linus Torvalds wrote: > On Wed, Apr 18, 2018 at 4:26 PM, Andi Kleen <a...@linux.intel.com> wrote: > > > > Seems like a hack. Why can't that be stored in a per cpu variable? > > It *is* a percpu variable - the whole x86_tss

Re: [PATCH 03/35] x86/entry/32: Load task stack from x86_tss.sp1 in SYSENTER handler

On Wed, Apr 18, 2018 at 05:02:02PM -0700, Linus Torvalds wrote: > On Wed, Apr 18, 2018 at 4:26 PM, Andi Kleen wrote: > > > > Seems like a hack. Why can't that be stored in a per cpu variable? > > It *is* a percpu variable - the whole x86_tss structure is percpu.

Re: [PATCH 03/35] x86/entry/32: Load task stack from x86_tss.sp1 in SYSENTER handler

Joerg Roedel writes: > From: Joerg Roedel > > We want x86_tss.sp0 point to the entry stack later to use > it as a trampoline stack for other kernel entry points > besides SYSENTER. > > So store the task stack pointer in x86_tss.sp1, which is > otherwise unused

Re: [PATCH 03/35] x86/entry/32: Load task stack from x86_tss.sp1 in SYSENTER handler

Joerg Roedel writes: > From: Joerg Roedel > > We want x86_tss.sp0 point to the entry stack later to use > it as a trampoline stack for other kernel entry points > besides SYSENTER. > > So store the task stack pointer in x86_tss.sp1, which is > otherwise unused by the hardware, as Linux doesn't

Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)

> Single-stepping is only a subset of the rseq limitations addressed > by cpu_opv. Anoher major limitation is algorithms requiring data > migration between per-cpu data structures safely against CPU hotplug, > and without having to change the cpu affinity mask. This is the case And how many

Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)

> Single-stepping is only a subset of the rseq limitations addressed > by cpu_opv. Anoher major limitation is algorithms requiring data > migration between per-cpu data structures safely against CPU hotplug, > and without having to change the cpu affinity mask. This is the case And how many

Re: [PATCH 17/17] perf annotate: Handle variables in 'sub', 'or' and many other instructions

> What do I miss? Or where is it that I'm misinterpreting the calculations > that objdump did in its output? The calculations are right, but these are still two different address modes. You cannot just turn one silently into the other. I think it would be ok to use the syntax in the assembler

Re: [PATCH 17/17] perf annotate: Handle variables in 'sub', 'or' and many other instructions

> What do I miss? Or where is it that I'm misinterpreting the calculations > that objdump did in its output? The calculations are right, but these are still two different address modes. You cannot just turn one silently into the other. I think it would be ok to use the syntax in the assembler

Re: [PATCH 17/17] perf annotate: Handle variables in 'sub', 'or' and many other instructions

On Fri, Apr 13, 2018 at 11:01:11AM -0300, Arnaldo Carvalho de Melo wrote: > From: Arnaldo Carvalho de Melo > > Just like is done for 'mov' and others that can have as source or > targets variables resolved by objdump, to make them more compact: > > - orb

Re: [PATCH 17/17] perf annotate: Handle variables in 'sub', 'or' and many other instructions

On Fri, Apr 13, 2018 at 11:01:11AM -0300, Arnaldo Carvalho de Melo wrote: > From: Arnaldo Carvalho de Melo > > Just like is done for 'mov' and others that can have as source or > targets variables resolved by objdump, to make them more compact: > > - orb$0x4,0x224d71(%rip)

Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)

> Can we plan on merging just the plain rseq parts *without* this all > first, and then see the cpu_opv thing as a "maybe future expansion" > part. That would be the right way to go. I doubt anybody really needs cpu_opv. We already have other code (e.g. vgettimeofday) which cannot be single

Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)

> Can we plan on merging just the plain rseq parts *without* this all > first, and then see the cpu_opv thing as a "maybe future expansion" > part. That would be the right way to go. I doubt anybody really needs cpu_opv. We already have other code (e.g. vgettimeofday) which cannot be single

Some minor fixes for perf user tools

This patchkit fixes some random minor issues in the perf user tools -Andi

Some minor fixes for perf user tools

This patchkit fixes some random minor issues in the perf user tools -Andi

[PATCH 1/4] perf, tools, mem: Allow all record/report options

From: Andi Kleen <a...@linux.intel.com> For perf mem report / perf mem record, pass all unknown options through to the underlying report/record commands. This makes things like perf mem record -a sleep 1 work. Matches how c2c and other tools work. Signed-off-by: Andi

[PATCH 1/4] perf, tools, mem: Allow all record/report options

From: Andi Kleen For perf mem report / perf mem record, pass all unknown options through to the underlying report/record commands. This makes things like perf mem record -a sleep 1 work. Matches how c2c and other tools work. Signed-off-by: Andi Kleen --- tools/perf/Documentation/perf

[PATCH 3/4] perf, tools, record: Remove misleading error suggestion

From: Andi Kleen <a...@linux.intel.com> When perf record encounters an error setting up an event it suggests to enable CONFIG_PERF_EVENTS. This is misleading because: - Usually it is enabled (it is really hard to disable on x86) - The problem is usually somewhere else, e.g. t

<    6   7   8   9   10   11   12   13   14   15   >