RE: [PATCH v4 1/4] x86/cpufeatures: Enumerate #DB for bus lock detection

2021-01-27 Thread Yu, Fenghua
Hi, Thomas, > On Wed, Jan 27, 2021 2:16 PM, Thomas Gleixner wrote: > On Tue, Nov 24 2020 at 20:52, Fenghua Yu wrote: > > > A bus lock is acquired though either split locked access to writeback > > (WB) memory or any locked access to non-WB memory. This is typically > > >1000 cycles slower than

RE: [PATCH v4 00/17] Miscellaneous fixes for resctrl selftests

2020-12-10 Thread Yu, Fenghua
Hi, Shuah, > This patch set has several miscellaneous fixes to resctrl selftest tool that > are > easily visible to user. V1 had fixes to CAT test and CMT test but they were > dropped in V2 because having them here made the patchset humongous. So, > changes to CAT test and CMT test will be

RE: [PATCH v4 0/4] x86/bus_lock: Enable bus lock detection

2020-12-02 Thread Yu, Fenghua
Hi, Dear maintainers, > A bus lock [1] is acquired through either split locked access to writeback > (WB) > memory or any locked access to non-WB memory. This is typically >1000 > cycles slower than an atomic operation within a cache line. It also disrupts > performance on other cores. ... >

RE: [PATCH v3 4/4] Documentation/admin-guide: Change doc for split_lock_detect parameter

2020-11-20 Thread Yu, Fenghua
Hi, Randy, > >>> + for bus lock detection. 0 < N <= HZ/2 and > >>> + N is approximate. Only applied to non-root > >>> + users. > >> > >> Sorry, but I don't know what this means. I think it's the "and N is > >>

RE: [PATCH v3 4/4] Documentation/admin-guide: Change doc for split_lock_detect parameter

2020-11-20 Thread Yu, Fenghua
Hi, Randy, > > + ratelimit:N - > > + Set rate limit to N bus locks per second > > + for bus lock detection. 0 < N <= HZ/2 and > > + N is approximate. Only applied to non-root > > +

RE: [PATCH v2 2/4] x86/bus_lock: Handle warn and fatal in #DB for bus lock

2020-11-19 Thread Yu, Fenghua
Hi, Peter, > > #DB for bus lock is enabled by bus lock detection bit 2 in DEBUGCTL > > MSR while #AC for split lock is enabled by split lock detection bit 29 > > in TEST_CTRL MSR. > > > > Delivery of #DB for bus lock in userspace clears DR6[11]. To avoid > > confusion in identifying #DB, #DB

RE: [PATCH 2/4] x86/bus_lock: Handle warn and fatal in #DB for bus lock

2020-11-10 Thread Yu, Fenghua
Hi, Peter, > On Sun, Nov 08, 2020 at 04:29:16AM +, Fenghua Yu wrote: > > split_lock_detect= > > #AC for split lock #DB for bus lock > > > > off Do nothing Do nothing > > > > warnKernel OOPs Warn once per

RE: [PATCH RFC] x86/bus_lock: Enable bus lock detection

2020-07-29 Thread Yu, Fenghua
Hi, Sean, > > A bus lock [1] is acquired either through split locked access to > > writeback (WB) memory or by using locks to uncacheable (UC) memory > > (e.g. direct device > > Does SLD not detect the lock to UC memory? The statement might not be accurate. Split Lock Detection doesn't detect

RE: [RFC PATCH] x86/cpufeatures: Enumerate new AVX512 bfloat16 instructions

2019-06-11 Thread Yu, Fenghua
> On Tuesday, June 11, 2019 3:28 PM, Fenghua Yu wrote: > On Tue, Jun 11, 2019 at 09:47:02PM +0200, Borislav Petkov wrote: > > On Tue, Jun 11, 2019 at 11:19:20AM -0700, Fenghua Yu wrote: > > > So can I re-organize word 11 and 12 as follows? > > > > > > 1. Change word 11 to host scattered features.

RE: [PATCH v3 3/5] x86/umwait: Add sysfs interface to control umwait C0.2 state

2019-05-30 Thread Yu, Fenghua
> On Thursday, May 30, 2019 2:11 PM Andy Lutomirski [mailto:l...@kernel.org] > wrote: > On Fri, May 24, 2019 at 5:05 PM Fenghua Yu wrote: > > > > C0.2 state in umwait and tpause instructions can be enabled or > > disabled on a processor through IA32_UMWAIT_CONTROL MSR register. > > > > By

RE: [PATCH v7 12/13] selftests/resctrl: Disable MBA and MBM tests for AMD

2019-05-10 Thread Yu, Fenghua
> On Friday, May 10, 2019 10:40 AM > Andre Przywara [mailto:andre.przyw...@arm.com] wrote: > To: Yu, Fenghua > Cc: Thomas Gleixner ; Ingo Molnar > ; Borislav Petkov ; H Peter Anvin > ; Luck, Tony ; Chatre, Reinette > ; Shankar, Ravi V ; > Shen, Xiaochen ; Pathan, Arshi

RE: [PATCH v7 00/13] selftests/resctrl: Add resctrl selftest

2019-05-10 Thread Yu, Fenghua
>On Friday, May 10, 2019 10:36 AM >Andre Przywara [mailto:andre.przyw...@arm.com] wrote: > On Sat, 9 Feb 2019 18:50:29 -0800 > Fenghua Yu wrote: > > Hi Fenghua, Babu, > > > With more and more resctrl features are being added by Intel, AMD and > > ARM, a test tool is becoming more and more

RE: [PATCH v7 02/13] selftests/resctrl: Add basic resctrl file system operations and data

2019-05-10 Thread Yu, Fenghua
> From: Andre Przywara [mailto:andre.przyw...@arm.com] > On Sat, 9 Feb 2019 18:50:31 -0800 > Fenghua Yu wrote: > > Hi, > > some comments inline. > > > From: Sai Praneeth Prakhya > > > > The basic resctrl file system operations and data are added for future > > usage by resctrl selftest tool.

RE: [PATCH v7 02/13] selftests/resctrl: Add basic resctrl file system operations and data

2019-05-10 Thread Yu, Fenghua
> From: Borislav Petkov [mailto:b...@alien8.de] > On Sat, Feb 09, 2019 at 06:50:31PM -0800, Fenghua Yu wrote: > > From: Sai Praneeth Prakhya > > > > The basic resctrl file system operations and data are added for future > > usage by resctrl selftest tool. > > > > Signed-off-by: Sai Praneeth

RE: [PATCH v4 05/17] x86/cpufeatures: Enumerate IA32_CORE_CAPABILITIES MSR

2019-03-04 Thread Yu, Fenghua
> From: Hansen, Dave > On 3/1/19 6:44 PM, Fenghua Yu wrote: > > diff --git a/arch/x86/include/asm/cpufeatures.h > b/arch/x86/include/asm/cpufeatures.h > > index 6d6122524711..350eeccd0ce9 100644 > > --- a/arch/x86/include/asm/cpufeatures.h > > +++ b/arch/x86/include/asm/cpufeatures.h > > @@ -349,6

RE: [PATCH v2 1/3] x86/cpufeatures: Enumerate user wait instructions

2019-02-21 Thread Yu, Fenghua
> From: Fenghua Yu [mailto:fenghua...@intel.com] > On Wed, Feb 20, 2019 at 10:37:27PM -0800, Andy Lutomirski wrote: > Or to simplify the situation, how about we still use zero as global max wait > time (i.e. no limitation for global wait time) as implemented in this patch > set? User can still

RE: [PATCH v3 10/10] x86/split_lock: Handle #AC exception for split lock

2019-02-13 Thread Yu, Fenghua
> From: Ingo Molnar [mailto:mingo.kernel@gmail.com] On Behalf Of Ingo Molnar > > On Mon, Feb 11, 2019 at 11:53:39AM +0100, Ingo Molnar wrote: > > > > + do_trap(trapnr, signr, str, regs, error_code, > > > > BUS_ADRALN, > NULL); > > > > + } > > > > +} > > > > > > Is there

RE: [PATCH v3 08/10] x86/setcpuid: Add kernel option setcpuid

2019-02-12 Thread Yu, Fenghua
> From: Peter Zijlstra [mailto:pet...@infradead.org] > On Tue, Feb 12, 2019 at 02:51:00PM +0100, Thomas Gleixner wrote: > > On Tue, 12 Feb 2019, Peter Zijlstra wrote: > > > > > On Mon, Feb 11, 2019 at 11:16:43AM -0800, Fenghua Yu wrote: > > > > 4. The feature can be disabled by kernel option > > >

RE: [PATCH v2 3/3] x86/umwait: Control umwait maximum time

2019-02-08 Thread Yu, Fenghua
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > On 17/01/2019 00:00, Andy Lutomirski wrote: > > On Wed, Jan 16, 2019 at 1:24 PM Fenghua Yu > wrote: > >> IA32_UMWAIT_CONTROL[31:2] determines the maximum time in TSC- > quanta > >> that processor can stay in C0.1 or C0.2. > >> > >> The

RE: [PATCH v4 10/10] selftests/resctrl: Add the test in MAINTAINERS

2019-01-02 Thread Yu, Fenghua
> From: Moger, Babu [mailto:babu.mo...@amd.com] > > F: Documentation/x86/intel_rdt* > > This patch does not apply cleanly. We have changed the above names from > intel_rdt to resctrl now. You need to re-base again. That's right. Will rebase this patch. Thanks. -Fenghua

RE: [PATCH v4 08/10] selftests/resctrl Add Cache QoS Monitoring (CQM) selftest

2019-01-02 Thread Yu, Fenghua
> From: Moger, Babu [mailto:babu.mo...@amd.com] > for (int i = 0; i < argc; i++) { >^ > resctrl_tests.c:39:56: note: previous declaration of 'i' was here > int res, c, core_id = 1, span = 250, argc_new = argc, i, no_of_bits = 5; >

RE: [REGRESSION][v4.14.y][v4.15] x86/intel_rdt/cqm: Improve limbo list processing

2018-01-16 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > On Tue, 16 Jan 2018, Joseph Salisbury wrote: > > On 01/16/2018 08:32 AM, Shankar, Ravi V wrote: > > > Vikas on vacation until end of the month. Fenghua will look into > > > this issue. > > > > > > On Jan 16, 2018, at 5:09 AM, Thomas Gleixner

RE: [REGRESSION][v4.14.y][v4.15] x86/intel_rdt/cqm: Improve limbo list processing

2018-01-16 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > On Tue, 16 Jan 2018, Joseph Salisbury wrote: > > On 01/16/2018 08:32 AM, Shankar, Ravi V wrote: > > > Vikas on vacation until end of the month. Fenghua will look into > > > this issue. > > > > > > On Jan 16, 2018, at 5:09 AM, Thomas Gleixner >

RE: [PATCH 4/6] x86/intel_rdt: Add two new resources for L2 Code and Data Prioritization (CDP)

2017-12-20 Thread Yu, Fenghua
> > When L2 CDP is enabled, the schemata will have the two resources in > > this format: > > L2DATA:l2id0=;l2id1=; > > L2CODE:l2id0=;l2id1=; > > Hi, > > What do the represent? The represents CBM (Cache Bit Mask) values in the schemata, similar to all others

RE: [PATCH 4/6] x86/intel_rdt: Add two new resources for L2 Code and Data Prioritization (CDP)

2017-12-20 Thread Yu, Fenghua
> > When L2 CDP is enabled, the schemata will have the two resources in > > this format: > > L2DATA:l2id0=;l2id1=; > > L2CODE:l2id0=;l2id1=; > > Hi, > > What do the represent? The represents CBM (Cache Bit Mask) values in the schemata, similar to all others

RE: [PATCH v2] x86/cpufeatures: Enable new SSE/AVX/AVX512 cpu features

2017-10-31 Thread Yu, Fenghua
> On Tuesday, October 31, 2017 11:33 AM, Borislav Petkov wrote: > On Tue, Oct 31, 2017 at 06:25:55PM +0000, Yu, Fenghua wrote: > > We may need to send a patch to fix a few legacy names that don't match > > exactly specs, e.g. AVX512VBMI as you mentioned. > > Or we c

RE: [PATCH v2] x86/cpufeatures: Enable new SSE/AVX/AVX512 cpu features

2017-10-31 Thread Yu, Fenghua
> On Tuesday, October 31, 2017 11:33 AM, Borislav Petkov wrote: > On Tue, Oct 31, 2017 at 06:25:55PM +0000, Yu, Fenghua wrote: > > We may need to send a patch to fix a few legacy names that don't match > > exactly specs, e.g. AVX512VBMI as you mentioned. > > Or we c

RE: [PATCH v2] x86/cpufeatures: Enable new SSE/AVX/AVX512 cpu features

2017-10-31 Thread Yu, Fenghua
> On Tuesday, October 31, 2017 11:03 AM, Yu, Fenghua wrote > > On Tuesday, October 31, 2017 3:06 AM, Borislav Petkov wrote: > > On Mon, Oct 30, 2017 at 06:20:29PM -0700, Gayatri Kammela wrote: > > > #define X86_FEATURE_AVX512VBMI (16*32+ 1) /* AVX512 Vector Bit >

RE: [PATCH v2] x86/cpufeatures: Enable new SSE/AVX/AVX512 cpu features

2017-10-31 Thread Yu, Fenghua
> On Tuesday, October 31, 2017 11:03 AM, Yu, Fenghua wrote > > On Tuesday, October 31, 2017 3:06 AM, Borislav Petkov wrote: > > On Mon, Oct 30, 2017 at 06:20:29PM -0700, Gayatri Kammela wrote: > > > #define X86_FEATURE_AVX512VBMI (16*32+ 1) /* AVX512 Vector Bit >

RE: [PATCH v2] x86/cpufeatures: Enable new SSE/AVX/AVX512 cpu features

2017-10-31 Thread Yu, Fenghua
> On Tuesday, October 31, 2017 3:06 AM, Borislav Petkov wrote: > On Mon, Oct 30, 2017 at 06:20:29PM -0700, Gayatri Kammela wrote: > > #define X86_FEATURE_AVX512VBMI (16*32+ 1) /* AVX512 Vector Bit > Manipulation instructions*/ > > So we have previous AVX512 feature bits which do not separate

RE: [PATCH v2] x86/cpufeatures: Enable new SSE/AVX/AVX512 cpu features

2017-10-31 Thread Yu, Fenghua
> On Tuesday, October 31, 2017 3:06 AM, Borislav Petkov wrote: > On Mon, Oct 30, 2017 at 06:20:29PM -0700, Gayatri Kammela wrote: > > #define X86_FEATURE_AVX512VBMI (16*32+ 1) /* AVX512 Vector Bit > Manipulation instructions*/ > > So we have previous AVX512 feature bits which do not separate

RE: [PATCH 3/3] x86/intel_rdt: Fix potential deadlock during resctrl mount

2017-10-20 Thread Yu, Fenghua
> From: Chatre, Reinette on Friday, October 20, 2017 2:17 AM > Subject: [PATCH 3/3] x86/intel_rdt: Fix potential deadlock during resctrl > mount Acked-by: Fenghua Yu <fenghua...@intel.com>

RE: [PATCH 3/3] x86/intel_rdt: Fix potential deadlock during resctrl mount

2017-10-20 Thread Yu, Fenghua
> From: Chatre, Reinette on Friday, October 20, 2017 2:17 AM > Subject: [PATCH 3/3] x86/intel_rdt: Fix potential deadlock during resctrl > mount Acked-by: Fenghua Yu

RE: [PATCH 2/3] x86/intel_rdt: Fix potential deadlock during resctrl unmount

2017-10-20 Thread Yu, Fenghua
> From: Chatre, Reinette on Friday, October 20, 2017 2:17 AM > Subject: [PATCH 2/3] x86/intel_rdt: Fix potential deadlock during resctrl > unmount > Acked-by: Fenghua Yu <fenghua...@intel.com>

RE: [PATCH 2/3] x86/intel_rdt: Fix potential deadlock during resctrl unmount

2017-10-20 Thread Yu, Fenghua
> From: Chatre, Reinette on Friday, October 20, 2017 2:17 AM > Subject: [PATCH 2/3] x86/intel_rdt: Fix potential deadlock during resctrl > unmount > Acked-by: Fenghua Yu

RE: [PATCH 00/14] Fix wrong %pF and %pS printk format specifier usages

2017-09-08 Thread Yu, Fenghua
> From: Sergey Senozhatsky [mailto:sergey.senozhatsky.w...@gmail.com] > On (09/07/17 16:05), Luck, Tony wrote: > +static inline bool __mod_text_address(struct module *mod, > + unsigned long addr) { > + /* Make sure it's within the text section. */ > +

RE: [PATCH 00/14] Fix wrong %pF and %pS printk format specifier usages

2017-09-08 Thread Yu, Fenghua
> From: Sergey Senozhatsky [mailto:sergey.senozhatsky.w...@gmail.com] > On (09/07/17 16:05), Luck, Tony wrote: > +static inline bool __mod_text_address(struct module *mod, > + unsigned long addr) { > + /* Make sure it's within the text section. */ > +

RE: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes

2017-02-01 Thread Yu, Fenghua
> From: Andi Kleen [mailto:a...@firstfloor.org] > "Luck, Tony" writes: > > 9) Measure per logical CPU (pick active RMID in same precedence for > task/cpu as CAT picks CLOSID) > > 10) Put multiple CPUs into a group > > I'm not sure this is a real requirement. It's just an

RE: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes

2017-02-01 Thread Yu, Fenghua
> From: Andi Kleen [mailto:a...@firstfloor.org] > "Luck, Tony" writes: > > 9) Measure per logical CPU (pick active RMID in same precedence for > task/cpu as CAT picks CLOSID) > > 10) Put multiple CPUs into a group > > I'm not sure this is a real requirement. It's just an optimization, right? If

RE: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes

2017-01-18 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > On Tue, 17 Jan 2017, Shivappa Vikas wrote: > > On Tue, 17 Jan 2017, Thomas Gleixner wrote: > > > On Fri, 6 Jan 2017, Vikas Shivappa wrote: > > > > - Issue(1): Inaccurate data for per package data, systemwide. Just > > > > prints zeros or

RE: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes

2017-01-18 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > On Tue, 17 Jan 2017, Shivappa Vikas wrote: > > On Tue, 17 Jan 2017, Thomas Gleixner wrote: > > > On Fri, 6 Jan 2017, Vikas Shivappa wrote: > > > > - Issue(1): Inaccurate data for per package data, systemwide. Just > > > > prints zeros or

RE: [PATCH] x86/intel_rdt: fix rdt_mount error handling

2016-11-08 Thread Yu, Fenghua
> From: Arnd Bergmann [mailto:a...@arndb.de] > The newly introduced rdt_mount function returns an unintialized pointer if > rdtgroup_create_info_dir() fails: > > arch/x86/kernel/cpu/intel_rdt_rdtgroup.c: In function ‘rdt_mount’: > arch/x86/kernel/cpu/intel_rdt_rdtgroup.c:710:9: error: ‘dentry’

RE: [PATCH] x86/intel_rdt: fix rdt_mount error handling

2016-11-08 Thread Yu, Fenghua
> From: Arnd Bergmann [mailto:a...@arndb.de] > The newly introduced rdt_mount function returns an unintialized pointer if > rdtgroup_create_info_dir() fails: > > arch/x86/kernel/cpu/intel_rdt_rdtgroup.c: In function ‘rdt_mount’: > arch/x86/kernel/cpu/intel_rdt_rdtgroup.c:710:9: error: ‘dentry’

RE: [PATCH v6 00/10] Intel Cache Allocation Technology

2016-10-30 Thread Yu, Fenghua
> Gentlemen! > > After more than two years of tinkering and real engineering, we finaly have > skinned the CAT! Yeah! We made it! > > That was the most amazing review journey I ever made as a maintainer. Just > a few statistics: > > Design variants: 6 > > 6 different approaches for a user

RE: [PATCH v6 00/10] Intel Cache Allocation Technology

2016-10-30 Thread Yu, Fenghua
> Gentlemen! > > After more than two years of tinkering and real engineering, we finaly have > skinned the CAT! Yeah! We made it! > > That was the most amazing review journey I ever made as a maintainer. Just > a few statistics: > > Design variants: 6 > > 6 different approaches for a user

RE: [PATCH v4 08/18] x86/intel_rdt: Pick up L3/L2 RDT parameters from CPUID

2016-10-17 Thread Yu, Fenghua
> > > I wonder whether this is the proper abstraction level. We might as > > > well do the following: > > > > > > rdtresources[] = { > > > { > > > .name = "L3", > > > }, > > > { > > > .name = "L3Data", > > > }, > > > { > > > .name = "L3Code", > > > }, > >

RE: [PATCH v4 08/18] x86/intel_rdt: Pick up L3/L2 RDT parameters from CPUID

2016-10-17 Thread Yu, Fenghua
> > > I wonder whether this is the proper abstraction level. We might as > > > well do the following: > > > > > > rdtresources[] = { > > > { > > > .name = "L3", > > > }, > > > { > > > .name = "L3Data", > > > }, > > > { > > > .name = "L3Code", > > > }, > >

RE: [PATCH v2 10/33] x86/intel_rdt: Implement scheduling support for Intel RDT

2016-09-15 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Thursday, September 08, 2016 2:54 AM > > On Thu, 8 Sep 2016, Fenghua Yu wrote: > > +extern struct static_key rdt_enable_key; void > > +__intel_rdt_sched_in(void *dummy); > > + > > struct clos_cbm_table { > > unsigned long cbm; > >

RE: [PATCH v2 10/33] x86/intel_rdt: Implement scheduling support for Intel RDT

2016-09-15 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Thursday, September 08, 2016 2:54 AM > > On Thu, 8 Sep 2016, Fenghua Yu wrote: > > +extern struct static_key rdt_enable_key; void > > +__intel_rdt_sched_in(void *dummy); > > + > > struct clos_cbm_table { > > unsigned long cbm; > >

RE: [PATCH v2 06/33] Documentation, x86: Documentation for Intel resource allocation user interface

2016-09-09 Thread Yu, Fenghua
> > Hmm, I don't know how applications are going to use the interface. > > Nobody knows it right now. But we do have some candicate workloads > > which want to configure the cache partition at runtime, so it's not > > just a boot time stuff. I'm wondering why we have such limitation. The > >

RE: [PATCH v2 06/33] Documentation, x86: Documentation for Intel resource allocation user interface

2016-09-09 Thread Yu, Fenghua
> > Hmm, I don't know how applications are going to use the interface. > > Nobody knows it right now. But we do have some candicate workloads > > which want to configure the cache partition at runtime, so it's not > > just a boot time stuff. I'm wondering why we have such limitation. The > >

RE: [PATCH v2 07/33] x86/intel_rdt: Add support for Cache Allocation detection

2016-09-08 Thread Yu, Fenghua
> > a line in cache ie when pulling new data into the cache. The > > programming of the hardware is done via programming MSRs (model > specific registers). > > > > Signed-off-by: Vikas Shivappa <vikas.shiva...@linux.intel.com> > > Signed-off-by: Fenghua Yu <fenghua...

RE: [PATCH v2 07/33] x86/intel_rdt: Add support for Cache Allocation detection

2016-09-08 Thread Yu, Fenghua
> From: Borislav Petkov [mailto:b...@suse.de] > On Thu, Sep 08, 2016 at 02:57:01AM -0700, Fenghua Yu wrote: > > From: Vikas Shivappa > > > > This patch includes CPUID enumeration routines for Cache allocation > > and new values to track resources to the cpuinfo_x86 structure. > > > > Cache

RE: [PATCH v2 07/33] x86/intel_rdt: Add support for Cache Allocation detection

2016-09-08 Thread Yu, Fenghua
> On Thu, 8 Sep 2016, Fenghua Yu wrote: > > + cpuid_count(0x0010, 1, , , , > ); > > + c->x86_l3_max_closid = edx + 1; > > + c->x86_l3_max_cbm_len = eax + 1; > > According to the SDM: > > EAX Bits 4:0: Length of the capacity bit mask

RE: [PATCH v2 07/33] x86/intel_rdt: Add support for Cache Allocation detection

2016-09-08 Thread Yu, Fenghua
> On Thu, 8 Sep 2016, Fenghua Yu wrote: > > + cpuid_count(0x0010, 1, , , , > ); > > + c->x86_l3_max_closid = edx + 1; > > + c->x86_l3_max_cbm_len = eax + 1; > > According to the SDM: > > EAX Bits 4:0: Length of the capacity bit mask

RE: [PATCH 13/32] Documentation, x86: Documentation for Intel resource allocation user interface

2016-08-04 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Tuesday, July 19, 2016 5:32 AM > On Thu, 14 Jul 2016, Luck, Tony wrote: > > So the core part of __intel_rdt_sched_in() will look like: > > > > rdtgrp = root_rdtgroup; > That can be done simpler. The default

RE: [PATCH 13/32] Documentation, x86: Documentation for Intel resource allocation user interface

2016-08-04 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Tuesday, July 19, 2016 5:32 AM > On Thu, 14 Jul 2016, Luck, Tony wrote: > > So the core part of __intel_rdt_sched_in() will look like: > > > > rdtgrp = root_rdtgroup; > That can be done simpler. The default

RE: [PATCH 06/32] x86/intel_rdt: Hot cpu support for Cache Allocation

2016-07-14 Thread Yu, Fenghua
> > > +static inline void intel_rdt_cpu_start(int cpu) { > > + struct intel_pqr_state *state = _cpu(pqr_state, cpu); > > + > > + state->closid = 0; > > + mutex_lock(_group_mutex); > > + if (rdt_cpumask_update(cpu)) > > + smp_call_function_single(cpu,

RE: [PATCH 06/32] x86/intel_rdt: Hot cpu support for Cache Allocation

2016-07-14 Thread Yu, Fenghua
> > > +static inline void intel_rdt_cpu_start(int cpu) { > > + struct intel_pqr_state *state = _cpu(pqr_state, cpu); > > + > > + state->closid = 0; > > + mutex_lock(_group_mutex); > > + if (rdt_cpumask_update(cpu)) > > + smp_call_function_single(cpu,

RE: [PATCH 30/32] x86/intel_rdt_rdtgroup.c: Process schemas input from rscctrl interface

2016-07-14 Thread Yu, Fenghua
> From: David Carrillo-Cisneros [mailto:davi...@google.com] > > +static int get_res_type(char **res, enum resource_type *res_type) { > > + char *tok; > > + > > + tok = strsep(res, ":"); > > + if (tok == NULL) > > + return -EINVAL; > > + > > + if (!strcmp(tok,

RE: [PATCH 30/32] x86/intel_rdt_rdtgroup.c: Process schemas input from rscctrl interface

2016-07-14 Thread Yu, Fenghua
> From: David Carrillo-Cisneros [mailto:davi...@google.com] > > +static int get_res_type(char **res, enum resource_type *res_type) { > > + char *tok; > > + > > + tok = strsep(res, ":"); > > + if (tok == NULL) > > + return -EINVAL; > > + > > + if (!strcmp(tok,

RE: [PATCH 30/32] x86/intel_rdt_rdtgroup.c: Process schemas input from rscctrl interface

2016-07-14 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Wednesday, July 13, 2016 11:11 PM > On Wed, 13 Jul 2016, David Carrillo-Cisneros wrote: > > > +static void free_cache_resource(struct cache_resource *l) { > > > + kfree(l->cbm); > > > + kfree(l->cbm2); > > > +

RE: [PATCH 30/32] x86/intel_rdt_rdtgroup.c: Process schemas input from rscctrl interface

2016-07-14 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Wednesday, July 13, 2016 11:11 PM > On Wed, 13 Jul 2016, David Carrillo-Cisneros wrote: > > > +static void free_cache_resource(struct cache_resource *l) { > > > + kfree(l->cbm); > > > + kfree(l->cbm2); > > > +

RE: [PATCH 24/32] Task fork and exit for rdtgroup

2016-07-13 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Wednesday, July 13, 2016 2:03 PM > On Wed, 13 Jul 2016, Yu, Fenghua wrote: > > On Wed, July 2016, Thomas Gleixner wrote > > > On Tue, 12 Jul 2016, Fenghua Yu wrote: > > > > +void rdtgroup

RE: [PATCH 24/32] Task fork and exit for rdtgroup

2016-07-13 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Wednesday, July 13, 2016 2:03 PM > On Wed, 13 Jul 2016, Yu, Fenghua wrote: > > On Wed, July 2016, Thomas Gleixner wrote > > > On Tue, 12 Jul 2016, Fenghua Yu wrote: > > > > +void rdtgroup

RE: [PATCH 08/32] Define CONFIG_INTEL_RDT

2016-07-13 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Wednesday, July 13, 2016 2:10 PM > On Wed, 13 Jul 2016, Yu, Fenghua wrote: > > Here is why this patch behaves like this: > > > > This patch and actually first 12 patches are directly from last year's >

RE: [PATCH 08/32] Define CONFIG_INTEL_RDT

2016-07-13 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Wednesday, July 13, 2016 2:10 PM > On Wed, 13 Jul 2016, Yu, Fenghua wrote: > > Here is why this patch behaves like this: > > > > This patch and actually first 12 patches are directly from last year's >

RE: [PATCH 08/32] Define CONFIG_INTEL_RDT

2016-07-13 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Wednesday, July 13, 2016 3:26 AM > On Tue, 12 Jul 2016, Fenghua Yu wrote: > > Subject: Define CONFIG_INTEL_RDT > > That does not qualify as a proper patch subject > > > From: Vikas Shivappa > > > >

RE: [PATCH 08/32] Define CONFIG_INTEL_RDT

2016-07-13 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Wednesday, July 13, 2016 3:26 AM > On Tue, 12 Jul 2016, Fenghua Yu wrote: > > Subject: Define CONFIG_INTEL_RDT > > That does not qualify as a proper patch subject > > > From: Vikas Shivappa > > > > CONFIG_INTEL_RDT is defined. > >

RE: [PATCH 19/32] sched.h: Add rg_list and rdtgroup in task_struct

2016-07-13 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Wednesday, July 13, 2016 5:56 AM > On Tue, 12 Jul 2016, Fenghua Yu wrote: > > From: Fenghua Yu <fenghua...@intel.com> > > > > rg_list is linked list to connect to other tasks in a rdtgroup. > > C

RE: [PATCH 19/32] sched.h: Add rg_list and rdtgroup in task_struct

2016-07-13 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Wednesday, July 13, 2016 5:56 AM > On Tue, 12 Jul 2016, Fenghua Yu wrote: > > From: Fenghua Yu > > > > rg_list is linked list to connect to other tasks in a rdtgroup. > > Can you please prefix that member proper, e.g. rdt_group_list

RE: [PATCH 23/32] x86/intel_rdt.c: Extend RDT to per cache and per resources

2016-07-13 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Wednesday, July 13, 2016 6:07 AM > To: Yu, Fenghua <fenghua...@intel.com> > Cc: Ingo Molnar <mi...@elte.hu>; Anvin, H Peter > <h.peter.an...@intel.com>; Luck, Tony <tony.l...@intel.com>; Tejun Heo

RE: [PATCH 23/32] x86/intel_rdt.c: Extend RDT to per cache and per resources

2016-07-13 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Wednesday, July 13, 2016 6:07 AM > To: Yu, Fenghua > Cc: Ingo Molnar ; Anvin, H Peter > ; Luck, Tony ; Tejun Heo > ; Borislav Petkov ; Stephane Eranian > ; Peter Zijlstra ; Marcelo > Tosatti ; David Carrillo-Cisn

RE: [PATCH v2 2/3] Documentation, ABI: Add a document entry for cache id

2016-07-08 Thread Yu, Fenghua
> From: Ingo Molnar [mailto:mingo.kernel@gmail.com] On Behalf Of Ingo > Molnar > Sent: Friday, July 08, 2016 1:42 AM > * Fenghua Yu <fenghua...@intel.com> wrote: > > > From: Fenghua Yu <fenghua...@intel.com> > > > > Add an ABI document entry for &

RE: [PATCH v2 2/3] Documentation, ABI: Add a document entry for cache id

2016-07-08 Thread Yu, Fenghua
> From: Ingo Molnar [mailto:mingo.kernel@gmail.com] On Behalf Of Ingo > Molnar > Sent: Friday, July 08, 2016 1:42 AM > * Fenghua Yu wrote: > > > From: Fenghua Yu > > > > Add an ABI document entry for > /sys/devices/system/cpu/cpu*/cache/index*/id. > > > > Signed-off-by: Fenghua Yu > > ---

RE: [PATCH v2 0/3] Cache id

2016-07-07 Thread Yu, Fenghua
> From: Borislav Petkov [mailto:b...@suse.de] > Sent: Thursday, July 07, 2016 9:21 AM > On Wed, Jul 06, 2016 at 03:07:15PM -0700, Fenghua Yu wrote: > > From: Fenghua Yu <fenghua...@intel.com> > > > > This patch set introduces cache id to identify a cache

RE: [PATCH v2 0/3] Cache id

2016-07-07 Thread Yu, Fenghua
> From: Borislav Petkov [mailto:b...@suse.de] > Sent: Thursday, July 07, 2016 9:21 AM > On Wed, Jul 06, 2016 at 03:07:15PM -0700, Fenghua Yu wrote: > > From: Fenghua Yu > > > > This patch set introduces cache id to identify a cache in platform. It > > can be useful in such areas as Cach

RE: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Yu, Fenghua
> From: Borislav Petkov [mailto:b...@suse.de] > Sent: Friday, July 01, 2016 11:36 AM > To: Yu, Fenghua <fenghua...@intel.com> > Cc: Luck, Tony <tony.l...@intel.com>; Thomas Gleixner > <t...@linutronix.de>; Ingo Molnar <mi...@elte.hu>; Anvin, H Peter >

RE: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Yu, Fenghua
> From: Borislav Petkov [mailto:b...@suse.de] > Sent: Friday, July 01, 2016 11:36 AM > To: Yu, Fenghua > Cc: Luck, Tony ; Thomas Gleixner > ; Ingo Molnar ; Anvin, H Peter > ; Peter Zijlstra ; > Stephane Eranian ; Shankar, Ravi V > ; Vikas Shivappa > ; linux-kernel k

RE: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Yu, Fenghua
> From: Borislav Petkov [mailto:b...@suse.de] > Sent: Friday, July 01, 2016 11:40 AM > On Fri, Jul 01, 2016 at 06:32:19PM +0000, Yu, Fenghua wrote: > > We has prefix "L3" or "L2" in the syntax, id is for that level in each > > line.b > > Give

RE: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Yu, Fenghua
> From: Borislav Petkov [mailto:b...@suse.de] > Sent: Friday, July 01, 2016 11:40 AM > On Fri, Jul 01, 2016 at 06:32:19PM +0000, Yu, Fenghua wrote: > > We has prefix "L3" or "L2" in the syntax, id is for that level in each > > line.b > > Give

RE: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Yu, Fenghua
> From: Borislav Petkov [mailto:b...@suse.de] > Sent: Friday, July 01, 2016 11:29 AM > To: Luck, Tony <tony.l...@intel.com> > Cc: Yu, Fenghua <fenghua...@intel.com>; Thomas Gleixner > <t...@linutronix.de>; Ingo Molnar <mi...@elte.hu>; Anvin, H Peter > <

RE: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Yu, Fenghua
> From: Borislav Petkov [mailto:b...@suse.de] > Sent: Friday, July 01, 2016 11:29 AM > To: Luck, Tony > Cc: Yu, Fenghua ; Thomas Gleixner > ; Ingo Molnar ; Anvin, H Peter > ; Peter Zijlstra ; > Stephane Eranian ; Shankar, Ravi V > ; Vikas Shivappa > ; linux-kernel k

RE: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Yu, Fenghua
> From: Borislav Petkov [mailto:b...@suse.de] > Sent: Friday, July 01, 2016 10:28 AM > To: Luck, Tony <tony.l...@intel.com> > Cc: Yu, Fenghua <fenghua...@intel.com>; Thomas Gleixner > <t...@linutronix.de>; Ingo Molnar <mi...@elte.hu>; Anvin, H Peter > <

RE: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Yu, Fenghua
> From: Borislav Petkov [mailto:b...@suse.de] > Sent: Friday, July 01, 2016 10:28 AM > To: Luck, Tony > Cc: Yu, Fenghua ; Thomas Gleixner > ; Ingo Molnar ; Anvin, H Peter > ; Peter Zijlstra ; > Stephane Eranian ; Shankar, Ravi V > ; Vikas Shivappa > ; linux-kernel k

RE: [PATCH 2/7] crypto : async implementation for sha1-mb

2016-05-26 Thread Yu, Fenghua
> From: Dey, Megha > Sent: Thursday, May 19, 2016 5:43 PM > To: herb...@gondor.apana.org.au > Cc: tim.c.c...@linux.intel.com; da...@davemloft.net; linux- > cry...@vger.kernel.org; linux-kernel@vger.kernel.org; Dey, Megha > <megha@intel.com>; Yu, Fenghua <fenghua

RE: [PATCH 2/7] crypto : async implementation for sha1-mb

2016-05-26 Thread Yu, Fenghua
> From: Dey, Megha > Sent: Thursday, May 19, 2016 5:43 PM > To: herb...@gondor.apana.org.au > Cc: tim.c.c...@linux.intel.com; da...@davemloft.net; linux- > cry...@vger.kernel.org; linux-kernel@vger.kernel.org; Dey, Megha > ; Yu, Fenghua ; Megha > Dey > Subject: [P

RE: [PATCH v6 01/13] x86/xsaves: Define and use fpu_user_xstate_size

2016-05-11 Thread Yu, Fenghua
Molnar > <mi...@redhat.com>; Dave Hansen <dave.han...@linux.intel.com>; Andy > Lutomirski <l...@kernel.org>; Prakhya, Sai Praneeth > <sai.praneeth.prak...@intel.com>; Shankar, Ravi V > <ravi.v.shan...@intel.com>; Yu, Fenghua <fenghua...@intel.com>

RE: [PATCH v6 01/13] x86/xsaves: Define and use fpu_user_xstate_size

2016-05-11 Thread Yu, Fenghua
> From: Borislav Petkov [mailto:b...@suse.de] > Sent: Wednesday, May 11, 2016 10:21 AM > To: Yu, Yu-cheng > Cc: linux-kernel@vger.kernel.org; x...@kernel.org; H. Peter Anvin > ; Thomas Gleixner ; Ingo Molnar > ; Dave Hansen ; Andy > Lutomirski ; Prakhya, Sai Praneeth >

RE: [PATCH 2/7] crypto: sha256-mb - SHA256 multibuffer job manager and glue code

2016-04-08 Thread Yu, Fenghua
> From: Herbert Xu [mailto:herb...@gondor.apana.org.au] > Sent: Tuesday, April 05, 2016 5:04 AM > To: megha@linux.intel.com > Cc: da...@davemloft.net; linux-cry...@vger.kernel.org; linux- > ker...@vger.kernel.org; tim.c.c...@linux.intel.com; Yu, Fenghua > <fenghua...@i

RE: [PATCH 2/7] crypto: sha256-mb - SHA256 multibuffer job manager and glue code

2016-04-08 Thread Yu, Fenghua
> From: Herbert Xu [mailto:herb...@gondor.apana.org.au] > Sent: Tuesday, April 05, 2016 5:04 AM > To: megha@linux.intel.com > Cc: da...@davemloft.net; linux-cry...@vger.kernel.org; linux- > ker...@vger.kernel.org; tim.c.c...@linux.intel.com; Yu, Fenghua > ; Dey, Megha >

RE: [PATCH 0/7] crypto: SHA256 multibuffer implementation

2016-04-04 Thread Yu, Fenghua
> From: megha@linux.intel.com [mailto:megha@linux.intel.com] > Sent: Thursday, March 24, 2016 1:26 PM > To: herb...@gondor.apana.org.au; da...@davemloft.net > Cc: linux-cry...@vger.kernel.org; linux-kernel@vger.kernel.org; > tim.c.c...@linux.intel.com; Yu, Fenghua <fe

RE: [PATCH 0/7] crypto: SHA256 multibuffer implementation

2016-04-04 Thread Yu, Fenghua
> From: megha@linux.intel.com [mailto:megha@linux.intel.com] > Sent: Thursday, March 24, 2016 1:26 PM > To: herb...@gondor.apana.org.au; da...@davemloft.net > Cc: linux-cry...@vger.kernel.org; linux-kernel@vger.kernel.org; > tim.c.c...@linux.intel.com; Yu, Fenghua ; Megha &

RE: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

2016-01-04 Thread Yu, Fenghua
> From: Richard Weinberger [mailto:richard.weinber...@gmail.com] > Sent: Saturday, January 02, 2016 2:54 PM > On Mon, Dec 21, 2015 at 6:05 PM, Marcelo Tosatti > wrote: > > OK cool hopefully that makes it clear to Fenghua Yu what must be > > changed in the patchset. > > > >> -

RE: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

2016-01-04 Thread Yu, Fenghua
> From: Richard Weinberger [mailto:richard.weinber...@gmail.com] > Sent: Saturday, January 02, 2016 2:54 PM > On Mon, Dec 21, 2015 at 6:05 PM, Marcelo Tosatti > wrote: > > OK cool hopefully that makes it clear to Fenghua Yu what must be > > changed in the patchset. > > > >>

RE: [RFD] CAT user space interface revisited

2015-12-22 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Wednesday, November 18, 2015 10:25 AM > Folks! > > After rereading the mail flood on CAT and staring into the SDM for a while, I > think we all should sit back and look at it from scratch again w/o our > preconceptions - I certainly had

RE: [RFD] CAT user space interface revisited

2015-12-22 Thread Yu, Fenghua
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Wednesday, November 18, 2015 10:25 AM > Folks! > > After rereading the mail flood on CAT and staring into the SDM for a while, I > think we all should sit back and look at it from scratch again w/o our > preconceptions - I certainly had

RE: [PATCH V15 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

2015-12-16 Thread Yu, Fenghua
> From: Marcelo Tosatti [mailto:mtosa...@redhat.com] > Sent: Wednesday, November 18, 2015 1:27 PM > To: Yu, Fenghua > Cc: H Peter Anvin ; Ingo Molnar ; > Thomas Gleixner ; Peter Zijlstra > ; linux-kernel ; x86 > ; Vikas Shivappa > Subject: Re: [PATCH V15 11/11] x8

RE: [PATCH V15 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

2015-12-16 Thread Yu, Fenghua
> From: Marcelo Tosatti [mailto:mtosa...@redhat.com] > Sent: Wednesday, November 18, 2015 1:27 PM > To: Yu, Fenghua <fenghua...@intel.com> > Cc: H Peter Anvin <h...@zytor.com>; Ingo Molnar <mi...@redhat.com>; > Thomas Gleixner <t...@linutronix.de>; Peter Z

RE: [PATCH V15 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

2015-12-14 Thread Yu, Fenghua
> From: Marcelo Tosatti [mailto:mtosa...@redhat.com] > Sent: Wednesday, November 18, 2015 2:15 PM > To: Yu, Fenghua > Cc: H Peter Anvin ; Ingo Molnar ; > Thomas Gleixner ; Peter Zijlstra > ; linux-kernel ; x86 > ; Vikas Shivappa > Subject: Re: [PATCH V15 11/11] x8

  1   2   3   >