On Mon, Apr 06, 2015 at 01:47:35PM -0400, Tejun Heo wrote:
> Hello, Preeti.
>
> On Thu, Apr 02, 2015 at 12:26:32PM +0530, Preeti U Murthy wrote:
> > By ensuring that the user configured cpusets are untouched, I don't see
> > how we affect userspace adversely. The expectation usually is that the
>
On Mon, Apr 06, 2015 at 01:47:35PM -0400, Tejun Heo wrote:
Hello, Preeti.
On Thu, Apr 02, 2015 at 12:26:32PM +0530, Preeti U Murthy wrote:
By ensuring that the user configured cpusets are untouched, I don't see
how we affect userspace adversely. The expectation usually is that the
kernel
Hello, Preeti.
On Thu, Apr 02, 2015 at 12:26:32PM +0530, Preeti U Murthy wrote:
> By ensuring that the user configured cpusets are untouched, I don't see
> how we affect userspace adversely. The expectation usually is that the
> kernel keeps track of the user configurations. If anything we would
Hello, Preeti.
On Thu, Apr 02, 2015 at 12:26:32PM +0530, Preeti U Murthy wrote:
By ensuring that the user configured cpusets are untouched, I don't see
how we affect userspace adversely. The expectation usually is that the
kernel keeps track of the user configurations. If anything we would be
Hi Tejun, Peter,
On 10/09/2014 06:36 PM, Tejun Heo wrote:
> On Thu, Oct 09, 2014 at 01:50:52PM +0530, Preeti U Murthy wrote:
>> However what remains to be answered is that the V2 of cgroup design -
>> the default hierarchy, tracks hotplug operations for children cgroups as
>> well. Tejun, Li,
Hi Tejun, Peter,
On 10/09/2014 06:36 PM, Tejun Heo wrote:
On Thu, Oct 09, 2014 at 01:50:52PM +0530, Preeti U Murthy wrote:
However what remains to be answered is that the V2 of cgroup design -
the default hierarchy, tracks hotplug operations for children cgroups as
well. Tejun, Li, will not
Hello, Peter.
On Thu, Oct 09, 2014 at 03:47:58PM +0200, Peter Zijlstra wrote:
> You do know we disagree on this :-)
Yeap. :)
...
> And while you all can try and pretend hotplug is a 'normal' and 'sane'
> operation with cpusets, the same failure more very much still exists
> with the regular
On Thu, Oct 09, 2014 at 09:06:11AM -0400, Tejun Heo wrote:
> On Thu, Oct 09, 2014 at 01:50:52PM +0530, Preeti U Murthy wrote:
> > However what remains to be answered is that the V2 of cgroup design -
> > the default hierarchy, tracks hotplug operations for children cgroups as
> > well. Tejun, Li,
On Thu, Oct 09, 2014 at 01:50:52PM +0530, Preeti U Murthy wrote:
> However what remains to be answered is that the V2 of cgroup design -
> the default hierarchy, tracks hotplug operations for children cgroups as
> well. Tejun, Li, will not the concerns that Peter raised above hold for
> the
On 10/09/2014 10:42 AM, Preeti U Murthy wrote:
Hi Raghu,
remove_tasks_in_empty_cpuset() is called on the legacy hierarchy when
the cpuset becomes empty, hence we require it. But you are right its not
called on the default hierarchy.
My point was if legacy hierarchy follows unified hierarchy
On Thu, Oct 09, 2014 at 01:50:52PM +0530, Preeti U Murthy wrote:
> >> SMT 8 on Power8 can help/hinder workloads. Hence we dynamically switch
> >> the modes at runtime.
> >
> > That's just a horrible piece of crap hack and you deserve any and all
> > pain you get from doing it.
> >
> > Randomly
On Thu, Oct 09, 2014 at 01:50:52PM +0530, Preeti U Murthy wrote:
> We observed this on ubuntu kernel, in which systemd explicitly mounts
Using systemd is your first fail.. total crapfest that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 10/08/2014 03:48 PM, Peter Zijlstra wrote:
> On Wed, Oct 08, 2014 at 03:07:51PM +0530, Preeti U Murthy wrote:
>
>>> I still completely hate all that.. It basically makes cpusets useless,
>>> they no longer guarantee anything, it makes then an optional placement
>>> hint instead.
>>
>> Why do
On 10/08/2014 03:48 PM, Peter Zijlstra wrote:
On Wed, Oct 08, 2014 at 03:07:51PM +0530, Preeti U Murthy wrote:
I still completely hate all that.. It basically makes cpusets useless,
they no longer guarantee anything, it makes then an optional placement
hint instead.
Why do you say they
On Thu, Oct 09, 2014 at 01:50:52PM +0530, Preeti U Murthy wrote:
We observed this on ubuntu kernel, in which systemd explicitly mounts
Using systemd is your first fail.. total crapfest that.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Thu, Oct 09, 2014 at 01:50:52PM +0530, Preeti U Murthy wrote:
SMT 8 on Power8 can help/hinder workloads. Hence we dynamically switch
the modes at runtime.
That's just a horrible piece of crap hack and you deserve any and all
pain you get from doing it.
Randomly removing/adding
On 10/09/2014 10:42 AM, Preeti U Murthy wrote:
Hi Raghu,
remove_tasks_in_empty_cpuset() is called on the legacy hierarchy when
the cpuset becomes empty, hence we require it. But you are right its not
called on the default hierarchy.
My point was if legacy hierarchy follows unified hierarchy
On Thu, Oct 09, 2014 at 01:50:52PM +0530, Preeti U Murthy wrote:
However what remains to be answered is that the V2 of cgroup design -
the default hierarchy, tracks hotplug operations for children cgroups as
well. Tejun, Li, will not the concerns that Peter raised above hold for
the default
On Thu, Oct 09, 2014 at 09:06:11AM -0400, Tejun Heo wrote:
On Thu, Oct 09, 2014 at 01:50:52PM +0530, Preeti U Murthy wrote:
However what remains to be answered is that the V2 of cgroup design -
the default hierarchy, tracks hotplug operations for children cgroups as
well. Tejun, Li, will
Hello, Peter.
On Thu, Oct 09, 2014 at 03:47:58PM +0200, Peter Zijlstra wrote:
You do know we disagree on this :-)
Yeap. :)
...
And while you all can try and pretend hotplug is a 'normal' and 'sane'
operation with cpusets, the same failure more very much still exists
with the regular
Hi Raghu,
On 10/08/2014 08:24 PM, Raghavendra KT wrote:
> On Wed, Oct 8, 2014 at 12:37 PM, Preeti U Murthy
> wrote:
>> There are two masks associated with cpusets. The cpus/mems_allowed
>> and effective_cpus/mems. On the legacy hierarchy both these masks
>> are consistent with each other. This
On Wed, Oct 8, 2014 at 12:37 PM, Preeti U Murthy
wrote:
> There are two masks associated with cpusets. The cpus/mems_allowed
> and effective_cpus/mems. On the legacy hierarchy both these masks
> are consistent with each other. This is the intersection of their
> value and the currently active
On Wed, Oct 08, 2014 at 03:07:51PM +0530, Preeti U Murthy wrote:
> > I still completely hate all that.. It basically makes cpusets useless,
> > they no longer guarantee anything, it makes then an optional placement
> > hint instead.
>
> Why do you say they don't guarantee anything? We ensure
Hi Peter,
On 10/08/2014 01:37 PM, Peter Zijlstra wrote:
> On Wed, Oct 08, 2014 at 12:37:40PM +0530, Preeti U Murthy wrote:
>> There are two masks associated with cpusets. The cpus/mems_allowed
>> and effective_cpus/mems. On the legacy hierarchy both these masks
>> are consistent with each other.
On Wed, Oct 08, 2014 at 12:37:40PM +0530, Preeti U Murthy wrote:
> There are two masks associated with cpusets. The cpus/mems_allowed
> and effective_cpus/mems. On the legacy hierarchy both these masks
> are consistent with each other. This is the intersection of their
> value and the currently
There are two masks associated with cpusets. The cpus/mems_allowed
and effective_cpus/mems. On the legacy hierarchy both these masks
are consistent with each other. This is the intersection of their
value and the currently active cpus. This means that we destroy the
original values set in these
There are two masks associated with cpusets. The cpus/mems_allowed
and effective_cpus/mems. On the legacy hierarchy both these masks
are consistent with each other. This is the intersection of their
value and the currently active cpus. This means that we destroy the
original values set in these
On Wed, Oct 08, 2014 at 12:37:40PM +0530, Preeti U Murthy wrote:
There are two masks associated with cpusets. The cpus/mems_allowed
and effective_cpus/mems. On the legacy hierarchy both these masks
are consistent with each other. This is the intersection of their
value and the currently active
Hi Peter,
On 10/08/2014 01:37 PM, Peter Zijlstra wrote:
On Wed, Oct 08, 2014 at 12:37:40PM +0530, Preeti U Murthy wrote:
There are two masks associated with cpusets. The cpus/mems_allowed
and effective_cpus/mems. On the legacy hierarchy both these masks
are consistent with each other. This is
On Wed, Oct 08, 2014 at 03:07:51PM +0530, Preeti U Murthy wrote:
I still completely hate all that.. It basically makes cpusets useless,
they no longer guarantee anything, it makes then an optional placement
hint instead.
Why do you say they don't guarantee anything? We ensure that we
On Wed, Oct 8, 2014 at 12:37 PM, Preeti U Murthy
pre...@linux.vnet.ibm.com wrote:
There are two masks associated with cpusets. The cpus/mems_allowed
and effective_cpus/mems. On the legacy hierarchy both these masks
are consistent with each other. This is the intersection of their
value and the
Hi Raghu,
On 10/08/2014 08:24 PM, Raghavendra KT wrote:
On Wed, Oct 8, 2014 at 12:37 PM, Preeti U Murthy
pre...@linux.vnet.ibm.com wrote:
There are two masks associated with cpusets. The cpus/mems_allowed
and effective_cpus/mems. On the legacy hierarchy both these masks
are consistent with
32 matches
Mail list logo
