On Fri, Sep 13, 2013 at 03:40:40PM +, Christoph Lameter wrote:
> Hmmm... usermodehelper is based on workqueues. I guess this will
> ultimately come down to modify the workqueue behavior for
> WORK_CPU_UNBOUND?
You don't need to keep it like that -- in fact I would suggest removing
that
On Fri, Sep 13, 2013 at 03:40:40PM +, Christoph Lameter wrote:
Hmmm... usermodehelper is based on workqueues. I guess this will
ultimately come down to modify the workqueue behavior for
WORK_CPU_UNBOUND?
You don't need to keep it like that -- in fact I would suggest removing
that
On Thu, Sep 12, 2013 at 9:35 PM, Frederic Weisbecker wrote:
>
> Just offline the CPUs you want to isolate, affine your kthreads and re-online
> the CPUs.
>
> If you're lucky enough to have 1024 CPUs, a winter night should be enough ;-)
Great, I have 4,096 CPUs. I guess I have to wait for the
On Thu, Sep 12, 2013 at 5:16 PM, Frederic Weisbecker wrote:
> On Thu, Sep 12, 2013 at 02:10:56PM +, Christoph Lameter wrote:
>> On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
>>
>> > Why not do this from userspace instead?
>>
>> Because the cpumasks are hardcoded in the kernel code.
>>
>
>
On Thu, Sep 12, 2013 at 5:16 PM, Frederic Weisbecker fweis...@gmail.com wrote:
On Thu, Sep 12, 2013 at 02:10:56PM +, Christoph Lameter wrote:
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
Why not do this from userspace instead?
Because the cpumasks are hardcoded in the kernel code.
On Thu, Sep 12, 2013 at 9:35 PM, Frederic Weisbecker fweis...@gmail.com wrote:
Just offline the CPUs you want to isolate, affine your kthreads and re-online
the CPUs.
If you're lucky enough to have 1024 CPUs, a winter night should be enough ;-)
Great, I have 4,096 CPUs. I guess I have to
On Fri, 13 Sep 2013, Peter Zijlstra wrote:
> No, creating a parent for them closes the race. It should also makes it
> lots easier to find the kids by using ppid.
Ok if all spawning is done from kthreadd then that works.
> > A kernel parameter would allow a clean bootup with threads
> >
Hmmm... usermodehelper is based on workqueues. I guess this will
ultimately come down to modify the workqueue behavior for
WORK_CPU_UNBOUND?
If WORK_CPU_UNBOUND could mean to limit process execution to the affinity
of kthreadd then we are fine.
That would also benefit many other workqueue events
> > If we really want to solve that race, then may be we can think of a
> > kernel_parameter
>
> No bloody kernel params. I'd much rather create a pointless kthread to
> act as usermodehelper parent that people can set context on (move it
> into cgroups, set affinity, whatever) so it
On Fri, Sep 13, 2013 at 01:54:53PM +, Christoph Lameter wrote:
>
> > > If we really want to solve that race, then may be we can think of a
> > > kernel_parameter
> >
> > No bloody kernel params. I'd much rather create a pointless kthread to
> > act as usermodehelper parent that people can
On Fri, 13 Sep 2013, Frederic Weisbecker wrote:
> Indeed, I just looked that again and your cpu_kthread_mask actually also
> applies to init.
> cpu_init_mask would be a better name I think.
Yea the naming is iffy. I want to get a general direction on how to are
going to address these issues
On Fri, Sep 13, 2013 at 01:45:55PM +, Christoph Lameter wrote:
> On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
>
> > So yeah it's a problem in theory. Now in practice, I have yet to be
> > convinced because
> > this should be solved after a few iterations in /proc in most cases.
>
> I
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
> So yeah it's a problem in theory. Now in practice, I have yet to be convinced
> because
> this should be solved after a few iterations in /proc in most cases.
I have seen some drivers regularly spawning threads all over the machnine.
This is a
On Thu, Sep 12, 2013 at 08:30:25PM +0200, Frederic Weisbecker wrote:
> Now the issue doesn't only concern kthreads but all tasks in the system.
No, only kernel threads, all other tasks have a parent they inherit
(namespace, cgroup, affinity etc..) context from.
> If we really want to solve that
On Thu, Sep 12, 2013 at 08:30:25PM +0200, Frederic Weisbecker wrote:
Now the issue doesn't only concern kthreads but all tasks in the system.
No, only kernel threads, all other tasks have a parent they inherit
(namespace, cgroup, affinity etc..) context from.
If we really want to solve that
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
So yeah it's a problem in theory. Now in practice, I have yet to be convinced
because
this should be solved after a few iterations in /proc in most cases.
I have seen some drivers regularly spawning threads all over the machnine.
This is a
On Fri, Sep 13, 2013 at 01:45:55PM +, Christoph Lameter wrote:
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
So yeah it's a problem in theory. Now in practice, I have yet to be
convinced because
this should be solved after a few iterations in /proc in most cases.
I have seen
On Fri, 13 Sep 2013, Frederic Weisbecker wrote:
Indeed, I just looked that again and your cpu_kthread_mask actually also
applies to init.
cpu_init_mask would be a better name I think.
Yea the naming is iffy. I want to get a general direction on how to are
going to address these issues before
On Fri, Sep 13, 2013 at 01:54:53PM +, Christoph Lameter wrote:
If we really want to solve that race, then may be we can think of a
kernel_parameter
No bloody kernel params. I'd much rather create a pointless kthread to
act as usermodehelper parent that people can set context on
If we really want to solve that race, then may be we can think of a
kernel_parameter
No bloody kernel params. I'd much rather create a pointless kthread to
act as usermodehelper parent that people can set context on (move it
into cgroups, set affinity, whatever) so it automagically
Hmmm... usermodehelper is based on workqueues. I guess this will
ultimately come down to modify the workqueue behavior for
WORK_CPU_UNBOUND?
If WORK_CPU_UNBOUND could mean to limit process execution to the affinity
of kthreadd then we are fine.
That would also benefit many other workqueue events
On Fri, 13 Sep 2013, Peter Zijlstra wrote:
No, creating a parent for them closes the race. It should also makes it
lots easier to find the kids by using ppid.
Ok if all spawning is done from kthreadd then that works.
A kernel parameter would allow a clean bootup with threads
starting out
On Thu, Sep 12, 2013 at 03:32:20PM +, Christoph Lameter wrote:
> On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
>
> > > Yea but the kernel option makes it easy. No extras needed. Kernel brings
> > > it up user space cleanly configured and ready to go.
> >
> > Ok but really that's just two
On Thu, Sep 12, 2013 at 08:35:05PM +0200, Frederic Weisbecker wrote:
> On Thu, Sep 12, 2013 at 08:39:22AM -0700, Paul E. McKenney wrote:
> > On Thu, Sep 12, 2013 at 05:11:04PM +0200, Frederic Weisbecker wrote:
> > > On Thu, Sep 12, 2013 at 02:52:56PM +, Christoph Lameter wrote:
> > > > On Thu,
On Thu, Sep 12, 2013 at 03:42:21PM +, Christoph Lameter wrote:
> Let me just say that the user space approach does not work because the
> kernel sets the cpumask to all and then spawns a thread f.e. for
> usermodehelper.
>
> This mean we would have to run a daemon that keeps scanning for
On Thu, Sep 12, 2013 at 08:39:22AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 12, 2013 at 05:11:04PM +0200, Frederic Weisbecker wrote:
> > On Thu, Sep 12, 2013 at 02:52:56PM +, Christoph Lameter wrote:
> > > On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
> > >
> > > > > > Ok but you can
Let me just say that the user space approach does not work because the
kernel sets the cpumask to all and then spawns a thread f.e. for
usermodehelper.
This mean we would have to run a daemon that keeps scanning for errand
threads and then move them. But at that point the damage would already
On Thu, Sep 12, 2013 at 05:11:04PM +0200, Frederic Weisbecker wrote:
> On Thu, Sep 12, 2013 at 02:52:56PM +, Christoph Lameter wrote:
> > On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
> >
> > > > > Ok but you can change the affinity of a kthread from userspace, as
> > > > > long as you
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
> > Yea but the kernel option makes it easy. No extras needed. Kernel brings
> > it up user space cleanly configured and ready to go.
>
> Ok but really that's just two lines of bash. I really wish we don't complicate
> core kernel code for that.
On Thu, Sep 12, 2013 at 02:52:56PM +, Christoph Lameter wrote:
> On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
>
> > > > Ok but you can change the affinity of a kthread from userspace, as
> > > > long as you define a cpu set that is among that kthread's cpus allowed.
> > >
> > > Ok but at
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
> > > Ok but you can change the affinity of a kthread from userspace, as
> > > long as you define a cpu set that is among that kthread's cpus allowed.
> >
> > Ok but at that point kthread has already spawned a lot of kernel threads.
> >
> > The same
On Thu, Sep 12, 2013 at 02:22:43PM +, Christoph Lameter wrote:
> On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
>
> > On Thu, Sep 12, 2013 at 02:10:56PM +, Christoph Lameter wrote:
> > > On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
> > >
> > > > Why not do this from userspace instead?
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
> On Thu, Sep 12, 2013 at 02:10:56PM +, Christoph Lameter wrote:
> > On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
> >
> > > Why not do this from userspace instead?
> >
> > Because the cpumasks are hardcoded in the kernel code.
> >
>
> Ok but
On Thu, Sep 12, 2013 at 02:10:56PM +, Christoph Lameter wrote:
> On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
>
> > Why not do this from userspace instead?
>
> Because the cpumasks are hardcoded in the kernel code.
>
Ok but you can change the affinity of a kthread from userspace, as
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
> Why not do this from userspace instead?
Because the cpumasks are hardcoded in the kernel code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
Why not do this from userspace instead?
Because the cpumasks are hardcoded in the kernel code.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Thu, Sep 12, 2013 at 02:10:56PM +, Christoph Lameter wrote:
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
Why not do this from userspace instead?
Because the cpumasks are hardcoded in the kernel code.
Ok but you can change the affinity of a kthread from userspace, as
long as
On Thu, Sep 12, 2013 at 02:22:43PM +, Christoph Lameter wrote:
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
On Thu, Sep 12, 2013 at 02:10:56PM +, Christoph Lameter wrote:
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
Why not do this from userspace instead?
Because
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
On Thu, Sep 12, 2013 at 02:10:56PM +, Christoph Lameter wrote:
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
Why not do this from userspace instead?
Because the cpumasks are hardcoded in the kernel code.
Ok but you can change
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
Ok but you can change the affinity of a kthread from userspace, as
long as you define a cpu set that is among that kthread's cpus allowed.
Ok but at that point kthread has already spawned a lot of kernel threads.
The same is true for
On Thu, Sep 12, 2013 at 02:52:56PM +, Christoph Lameter wrote:
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
Ok but you can change the affinity of a kthread from userspace, as
long as you define a cpu set that is among that kthread's cpus allowed.
Ok but at that point
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
Yea but the kernel option makes it easy. No extras needed. Kernel brings
it up user space cleanly configured and ready to go.
Ok but really that's just two lines of bash. I really wish we don't complicate
core kernel code for that.
Thread
On Thu, Sep 12, 2013 at 05:11:04PM +0200, Frederic Weisbecker wrote:
On Thu, Sep 12, 2013 at 02:52:56PM +, Christoph Lameter wrote:
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
Ok but you can change the affinity of a kthread from userspace, as
long as you define a cpu set
Let me just say that the user space approach does not work because the
kernel sets the cpumask to all and then spawns a thread f.e. for
usermodehelper.
This mean we would have to run a daemon that keeps scanning for errand
threads and then move them. But at that point the damage would already
On Thu, Sep 12, 2013 at 08:39:22AM -0700, Paul E. McKenney wrote:
On Thu, Sep 12, 2013 at 05:11:04PM +0200, Frederic Weisbecker wrote:
On Thu, Sep 12, 2013 at 02:52:56PM +, Christoph Lameter wrote:
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
Ok but you can change the
On Thu, Sep 12, 2013 at 03:32:20PM +, Christoph Lameter wrote:
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
Yea but the kernel option makes it easy. No extras needed. Kernel brings
it up user space cleanly configured and ready to go.
Ok but really that's just two lines of bash.
On Thu, Sep 12, 2013 at 03:42:21PM +, Christoph Lameter wrote:
Let me just say that the user space approach does not work because the
kernel sets the cpumask to all and then spawns a thread f.e. for
usermodehelper.
This mean we would have to run a daemon that keeps scanning for errand
On Thu, Sep 12, 2013 at 08:35:05PM +0200, Frederic Weisbecker wrote:
On Thu, Sep 12, 2013 at 08:39:22AM -0700, Paul E. McKenney wrote:
On Thu, Sep 12, 2013 at 05:11:04PM +0200, Frederic Weisbecker wrote:
On Thu, Sep 12, 2013 at 02:52:56PM +, Christoph Lameter wrote:
On Thu, 12 Sep
On Wed, 2013-09-11 at 23:36 +0200, Frederic Weisbecker wrote:
> On Wed, Sep 11, 2013 at 02:21:06PM +, Christoph Lameter wrote:
> > On Wed, 11 Sep 2013, Mike Galbraith wrote:
> >
> > > Mind saying why? To me, creating properties of exclusive sets of CPUs
> > > that the interface which
On Thu, Sep 05, 2013 at 08:07:37PM +, Christoph Lameter wrote:
> I am not sure how to call this kernel option but we need something like
> that. I see drivers and the kernel spawning processes on the nohz cores.
> The name kthread is not really catching the purpose.
>
> os_cpus=?
On Wed, Sep 11, 2013 at 02:21:06PM +, Christoph Lameter wrote:
> On Wed, 11 Sep 2013, Mike Galbraith wrote:
>
> > Mind saying why? To me, creating properties of exclusive sets of CPUs
> > that the interface which manages sets and their properties is not fully
> > aware of is a dainbramaged
Here is a draft of a patch to do autoconfig if CONFIG_NO_HZ_FULL_ALL is
set.
Subject: Simple autoconfig for tickless system
This is on top of the prior patch that restricts the cpus that
kthread can spawn processes on.
It ensures that one processor per node is kept in regular
HZ mode and also
On Wed, 2013-09-11 at 14:21 +, Christoph Lameter wrote:
> On Wed, 11 Sep 2013, Mike Galbraith wrote:
>
> > Mind saying why? To me, creating properties of exclusive sets of CPUs
> > that the interface which manages sets and their properties is not fully
> > aware of is a dainbramaged thing
On Wed, 11 Sep 2013, Mike Galbraith wrote:
> Mind saying why? To me, creating properties of exclusive sets of CPUs
> that the interface which manages sets and their properties is not fully
> aware of is a dainbramaged thing to do.
cpusets is being replaced by cgropus. And the mechanism adds
On Wed, 11 Sep 2013, Mike Galbraith wrote:
Mind saying why? To me, creating properties of exclusive sets of CPUs
that the interface which manages sets and their properties is not fully
aware of is a dainbramaged thing to do.
cpusets is being replaced by cgropus. And the mechanism adds some
On Wed, 2013-09-11 at 14:21 +, Christoph Lameter wrote:
On Wed, 11 Sep 2013, Mike Galbraith wrote:
Mind saying why? To me, creating properties of exclusive sets of CPUs
that the interface which manages sets and their properties is not fully
aware of is a dainbramaged thing to do.
Here is a draft of a patch to do autoconfig if CONFIG_NO_HZ_FULL_ALL is
set.
Subject: Simple autoconfig for tickless system
This is on top of the prior patch that restricts the cpus that
kthread can spawn processes on.
It ensures that one processor per node is kept in regular
HZ mode and also
On Wed, Sep 11, 2013 at 02:21:06PM +, Christoph Lameter wrote:
On Wed, 11 Sep 2013, Mike Galbraith wrote:
Mind saying why? To me, creating properties of exclusive sets of CPUs
that the interface which manages sets and their properties is not fully
aware of is a dainbramaged thing to
On Thu, Sep 05, 2013 at 08:07:37PM +, Christoph Lameter wrote:
I am not sure how to call this kernel option but we need something like
that. I see drivers and the kernel spawning processes on the nohz cores.
The name kthread is not really catching the purpose.
os_cpus=?
On Wed, 2013-09-11 at 23:36 +0200, Frederic Weisbecker wrote:
On Wed, Sep 11, 2013 at 02:21:06PM +, Christoph Lameter wrote:
On Wed, 11 Sep 2013, Mike Galbraith wrote:
Mind saying why? To me, creating properties of exclusive sets of CPUs
that the interface which manages sets and
On Tue, 2013-09-10 at 21:10 +, Christoph Lameter wrote:
> On Tue, 10 Sep 2013, Gilad Ben-Yossef wrote:
>
> > On Tue, Sep 10, 2013 at 10:26 AM, Mike Galbraith
> > wrote:
> >
> > >
> > > Hammering on the wrong spot makes removing isolcpus take longer, and
> > > adds up to more hammering in
On Tue, 10 Sep 2013, Rob Landley wrote:
> On 09/05/2013 03:07:37 PM, Christoph Lameter wrote:
> > I am not sure how to call this kernel option but we need something like
> > that. I see drivers and the kernel spawning processes on the nohz cores.
> > The name kthread is not really catching the
On Tue, 10 Sep 2013, Gilad Ben-Yossef wrote:
> as little interference as possible, one needs to pass
> rcu_nocbs, isolcpus, nohz_full parameters and now kthread parameter,
> all pretty much with the same values
>
> I know some people won't like this, but can we perhaps fold all these
> into a
On Tue, 10 Sep 2013, Gilad Ben-Yossef wrote:
> On Tue, Sep 10, 2013 at 10:26 AM, Mike Galbraith wrote:
>
> >
> > Hammering on the wrong spot makes removing isolcpus take longer, and
> > adds up to more hammering in the long run, no? Hearing you mention
> > isolcpus, I just thought I should
On 09/05/2013 03:07:37 PM, Christoph Lameter wrote:
I am not sure how to call this kernel option but we need something
like
that. I see drivers and the kernel spawning processes on the nohz
cores.
The name kthread is not really catching the purpose.
Can't you just use the CPU affinity of
On Tue, 2013-09-10 at 10:56 +0300, Gilad Ben-Yossef wrote:
> What if we re-did the implementation of isolcpu as creating an
> cpuset with migration off as early as possible in the boot process, prior to
> spawning init?
>
> So basically, isolcpus becomes just a way to configure a cpuset early?
On Tue, Sep 10, 2013 at 10:26 AM, Mike Galbraith wrote:
>
> Hammering on the wrong spot makes removing isolcpus take longer, and
> adds up to more hammering in the long run, no? Hearing you mention
> isolcpus, I just thought I should mention that it wants to go away, so
> might not be the
On Tue, 2013-09-10 at 09:59 +0300, Gilad Ben-Yossef wrote:
> Hi,
>
>
> On Tue, Sep 10, 2013 at 9:47 AM, Mike Galbraith wrote:
> >
> > On Tue, 2013-09-10 at 09:05 +0300, Gilad Ben-Yossef wrote:
> > > Hi,
> > >
> > > On Thu, Sep 5, 2013 at 11:07 PM, Christoph Lameter wrote:
> > > > I am not
Hi,
On Tue, Sep 10, 2013 at 9:47 AM, Mike Galbraith wrote:
>
> On Tue, 2013-09-10 at 09:05 +0300, Gilad Ben-Yossef wrote:
> > Hi,
> >
> > On Thu, Sep 5, 2013 at 11:07 PM, Christoph Lameter wrote:
> > > I am not sure how to call this kernel option but we need something like
> > > that. I see
On Tue, 2013-09-10 at 09:05 +0300, Gilad Ben-Yossef wrote:
> Hi,
>
> On Thu, Sep 5, 2013 at 11:07 PM, Christoph Lameter wrote:
> > I am not sure how to call this kernel option but we need something like
> > that. I see drivers and the kernel spawning processes on the nohz cores.
> > The name
Hi,
On Thu, Sep 5, 2013 at 11:07 PM, Christoph Lameter wrote:
> I am not sure how to call this kernel option but we need something like
> that. I see drivers and the kernel spawning processes on the nohz cores.
> The name kthread is not really catching the purpose.
>
> os_cpus=?
Hi,
On Thu, Sep 5, 2013 at 11:07 PM, Christoph Lameter c...@linux.com wrote:
I am not sure how to call this kernel option but we need something like
that. I see drivers and the kernel spawning processes on the nohz cores.
The name kthread is not really catching the purpose.
os_cpus=?
On Tue, 2013-09-10 at 09:05 +0300, Gilad Ben-Yossef wrote:
Hi,
On Thu, Sep 5, 2013 at 11:07 PM, Christoph Lameter c...@linux.com wrote:
I am not sure how to call this kernel option but we need something like
that. I see drivers and the kernel spawning processes on the nohz cores.
The
Hi,
On Tue, Sep 10, 2013 at 9:47 AM, Mike Galbraith bitbuc...@online.de wrote:
On Tue, 2013-09-10 at 09:05 +0300, Gilad Ben-Yossef wrote:
Hi,
On Thu, Sep 5, 2013 at 11:07 PM, Christoph Lameter c...@linux.com wrote:
I am not sure how to call this kernel option but we need something
On Tue, 2013-09-10 at 09:59 +0300, Gilad Ben-Yossef wrote:
Hi,
On Tue, Sep 10, 2013 at 9:47 AM, Mike Galbraith bitbuc...@online.de wrote:
On Tue, 2013-09-10 at 09:05 +0300, Gilad Ben-Yossef wrote:
Hi,
On Thu, Sep 5, 2013 at 11:07 PM, Christoph Lameter c...@linux.com wrote:
On Tue, Sep 10, 2013 at 10:26 AM, Mike Galbraith bitbuc...@online.de wrote:
Hammering on the wrong spot makes removing isolcpus take longer, and
adds up to more hammering in the long run, no? Hearing you mention
isolcpus, I just thought I should mention that it wants to go away, so
might
On Tue, 2013-09-10 at 10:56 +0300, Gilad Ben-Yossef wrote:
What if we re-did the implementation of isolcpu as creating an
cpuset with migration off as early as possible in the boot process, prior to
spawning init?
So basically, isolcpus becomes just a way to configure a cpuset early?
On 09/05/2013 03:07:37 PM, Christoph Lameter wrote:
I am not sure how to call this kernel option but we need something
like
that. I see drivers and the kernel spawning processes on the nohz
cores.
The name kthread is not really catching the purpose.
Can't you just use the CPU affinity of
On Tue, 10 Sep 2013, Gilad Ben-Yossef wrote:
On Tue, Sep 10, 2013 at 10:26 AM, Mike Galbraith bitbuc...@online.de wrote:
Hammering on the wrong spot makes removing isolcpus take longer, and
adds up to more hammering in the long run, no? Hearing you mention
isolcpus, I just thought I
On Tue, 10 Sep 2013, Gilad Ben-Yossef wrote:
as little interference as possible, one needs to pass
rcu_nocbs, isolcpus, nohz_full parameters and now kthread parameter,
all pretty much with the same values
I know some people won't like this, but can we perhaps fold all these
into a single
On Tue, 10 Sep 2013, Rob Landley wrote:
On 09/05/2013 03:07:37 PM, Christoph Lameter wrote:
I am not sure how to call this kernel option but we need something like
that. I see drivers and the kernel spawning processes on the nohz cores.
The name kthread is not really catching the purpose.
On Tue, 2013-09-10 at 21:10 +, Christoph Lameter wrote:
On Tue, 10 Sep 2013, Gilad Ben-Yossef wrote:
On Tue, Sep 10, 2013 at 10:26 AM, Mike Galbraith bitbuc...@online.de
wrote:
Hammering on the wrong spot makes removing isolcpus take longer, and
adds up to more hammering in
I am not sure how to call this kernel option but we need something like
that. I see drivers and the kernel spawning processes on the nohz cores.
The name kthread is not really catching the purpose.
os_cpus=? highlatency_cpus=?
Subject: Restrict kernel spawning of threads to a specified set of
I am not sure how to call this kernel option but we need something like
that. I see drivers and the kernel spawning processes on the nohz cores.
The name kthread is not really catching the purpose.
os_cpus=? highlatency_cpus=?
Subject: Restrict kernel spawning of threads to a specified set of
84 matches
Mail list logo
