On Mon, 10 Apr 2017, Thomas Gleixner wrote:
On Wed, 5 Apr 2017, Luck, Tony wrote:
On Wed, Apr 05, 2017 at 05:20:24PM +0200, Thomas Gleixner wrote:
That's just wrong.
The proper behaviour for a new control group is, that at the time when it
is created it copies the CBM values of the default
On Mon, 10 Apr 2017, Thomas Gleixner wrote:
On Wed, 5 Apr 2017, Luck, Tony wrote:
On Wed, Apr 05, 2017 at 05:20:24PM +0200, Thomas Gleixner wrote:
That's just wrong.
The proper behaviour for a new control group is, that at the time when it
is created it copies the CBM values of the default
On Wed, 5 Apr 2017, Luck, Tony wrote:
> On Wed, Apr 05, 2017 at 05:20:24PM +0200, Thomas Gleixner wrote:
> > That's just wrong.
> >
> > The proper behaviour for a new control group is, that at the time when it
> > is created it copies the CBM values of the default group and not claiming
> >
On Wed, 5 Apr 2017, Luck, Tony wrote:
> On Wed, Apr 05, 2017 at 05:20:24PM +0200, Thomas Gleixner wrote:
> > That's just wrong.
> >
> > The proper behaviour for a new control group is, that at the time when it
> > is created it copies the CBM values of the default group and not claiming
> >
On Wed, Apr 05, 2017 at 11:07:37AM -0700, Luck, Tony wrote:
> On Wed, Apr 05, 2017 at 05:20:24PM +0200, Thomas Gleixner wrote:
> > That's just wrong.
> >
> > The proper behaviour for a new control group is, that at the time when it
> > is created it copies the CBM values of the default group and
On Wed, Apr 05, 2017 at 11:07:37AM -0700, Luck, Tony wrote:
> On Wed, Apr 05, 2017 at 05:20:24PM +0200, Thomas Gleixner wrote:
> > That's just wrong.
> >
> > The proper behaviour for a new control group is, that at the time when it
> > is created it copies the CBM values of the default group and
On Wed, Apr 05, 2017 at 05:20:24PM +0200, Thomas Gleixner wrote:
> That's just wrong.
>
> The proper behaviour for a new control group is, that at the time when it
> is created it copies the CBM values of the default group and not claiming
> access to ALL of the cache by default.
I don't see
On Wed, Apr 05, 2017 at 05:20:24PM +0200, Thomas Gleixner wrote:
> That's just wrong.
>
> The proper behaviour for a new control group is, that at the time when it
> is created it copies the CBM values of the default group and not claiming
> access to ALL of the cache by default.
I don't see
On Wed, 5 Apr 2017, Thomas Gleixner wrote:
On Mon, 3 Apr 2017, Vikas Shivappa wrote:
Subject: x86/intel_rdt: Fix issue when mkdir uses a freed CLOSid
This subject line is useless again. It want's to be descriptive.
"Fix issue" Which issue?
Each resctrl directory has one CLOSid
On Wed, 5 Apr 2017, Thomas Gleixner wrote:
On Mon, 3 Apr 2017, Vikas Shivappa wrote:
Subject: x86/intel_rdt: Fix issue when mkdir uses a freed CLOSid
This subject line is useless again. It want's to be descriptive.
"Fix issue" Which issue?
Each resctrl directory has one CLOSid
On Mon, 3 Apr 2017, Vikas Shivappa wrote:
> Subject: x86/intel_rdt: Fix issue when mkdir uses a freed CLOSid
This subject line is useless again. It want's to be descriptive.
"Fix issue" Which issue?
> Each resctrl directory has one CLOSid allocated which is mapped to a
> control
On Mon, 3 Apr 2017, Vikas Shivappa wrote:
> Subject: x86/intel_rdt: Fix issue when mkdir uses a freed CLOSid
This subject line is useless again. It want's to be descriptive.
"Fix issue" Which issue?
> Each resctrl directory has one CLOSid allocated which is mapped to a
> control
Each resctrl directory has one CLOSid allocated which is mapped to a
control register/QOS_MSR. During an rmdir this CLOSid is freed and can
be reused later when a new directory is created. Currently we do not
reset the QOS_MSR to a default when the CLOSid is freed. So when the
next mkdir uses a
Each resctrl directory has one CLOSid allocated which is mapped to a
control register/QOS_MSR. During an rmdir this CLOSid is freed and can
be reused later when a new directory is created. Currently we do not
reset the QOS_MSR to a default when the CLOSid is freed. So when the
next mkdir uses a
14 matches
Mail list logo
