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
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
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.
...
>
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
> >>
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
> > +
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
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
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
> 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.
> 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
> 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
>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
> 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.
> 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
> 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
> 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
> 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
> 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
> > >
> 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
> 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
> 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;
>
> 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
> 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 >
> > 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
> > 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
> 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
> 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
> 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
>
> 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
>
> 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
> 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
> 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>
> 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
> 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>
> 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
> 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. */
> +
> 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. */
> +
> 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
> 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
> 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
> 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
> 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’
> 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’
> 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
> 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
> > > I wonder whether this is the proper abstraction level. We might as
> > > well do the following:
> > >
> > > rdtresources[] = {
> > > {
> > > .name = "L3",
> > > },
> > > {
> > > .name = "L3Data",
> > > },
> > > {
> > > .name = "L3Code",
> > > },
> >
> > > I wonder whether this is the proper abstraction level. We might as
> > > well do the following:
> > >
> > > rdtresources[] = {
> > > {
> > > .name = "L3",
> > > },
> > > {
> > > .name = "L3Data",
> > > },
> > > {
> > > .name = "L3Code",
> > > },
> >
> 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;
> >
> 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;
> >
> > 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
> >
> > 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
> >
> > 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...
> 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
> 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
> 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
> 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
> 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
>
> > +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,
>
> > +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,
> 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,
> 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,
> 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);
> > > +
> 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);
> > > +
> 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
> 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
> 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
>
> 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
>
> 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
> >
> >
> 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.
>
>
> 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
> 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
> 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
> 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
> 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
&
> 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
> > ---
> 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
> 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
> 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
>
> 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
> 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
> 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
> 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
> <
> 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
> 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
> <
> 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
> 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
> 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
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>
> 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
>
> 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
> 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
>
> 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
> 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
&
> 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.
> >
> >> -
> 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.
> >
> >>
> 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
> 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
> 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
> 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
> 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 - 100 of 269 matches
Mail list logo