On Tue, Apr 08, 2014 at 01:57:12PM -0700, Andrew Morton wrote:
> On Fri, 8 Nov 2013 21:06:22 +0100 Frederic Weisbecker
> wrote:
>
> > On Fri, Nov 08, 2013 at 07:52:37PM +, Christoph Lameter wrote:
> > > On Fri, 8 Nov 2013, Frederic Weisbecker wrote:
> > >
> > > > I understand, but why not
On Fri, 8 Nov 2013 21:06:22 +0100 Frederic Weisbecker
wrote:
> On Fri, Nov 08, 2013 at 07:52:37PM +, Christoph Lameter wrote:
> > On Fri, 8 Nov 2013, Frederic Weisbecker wrote:
> >
> > > I understand, but why not solving that from the workqueue affinity? We
> > > want to
> > > solve the
On Fri, 8 Nov 2013 21:06:22 +0100 Frederic Weisbecker fweis...@gmail.com
wrote:
On Fri, Nov 08, 2013 at 07:52:37PM +, Christoph Lameter wrote:
On Fri, 8 Nov 2013, Frederic Weisbecker wrote:
I understand, but why not solving that from the workqueue affinity? We
want to
solve
On Tue, Apr 08, 2014 at 01:57:12PM -0700, Andrew Morton wrote:
On Fri, 8 Nov 2013 21:06:22 +0100 Frederic Weisbecker fweis...@gmail.com
wrote:
On Fri, Nov 08, 2013 at 07:52:37PM +, Christoph Lameter wrote:
On Fri, 8 Nov 2013, Frederic Weisbecker wrote:
I understand, but why
On Fri, Nov 08, 2013 at 07:52:37PM +, Christoph Lameter wrote:
> On Fri, 8 Nov 2013, Frederic Weisbecker wrote:
>
> > I understand, but why not solving that from the workqueue affinity? We want
> > to
> > solve the issue of unbound workqueues in CPU isolation anyway.
>
> Sure if you can
On Fri, 8 Nov 2013, Frederic Weisbecker wrote:
> I understand, but why not solving that from the workqueue affinity? We want to
> solve the issue of unbound workqueues in CPU isolation anyway.
Sure if you can solve that with an unbound work queue then this patch is
not needed. Do you have a
On Fri, Nov 08, 2013 at 05:05:35PM +, Christoph Lameter wrote:
> On Fri, 8 Nov 2013, Frederic Weisbecker wrote:
>
> > But it looks like it always end up calling a workqueue. May be I missed
> > something though.
> >
> > Now we can argue that this workqueue seem to create kernel threads,
On Fri, 8 Nov 2013, Frederic Weisbecker wrote:
> But it looks like it always end up calling a workqueue. May be I missed
> something though.
>
> Now we can argue that this workqueue seem to create kernel threads, which in
> turn create other kernel thread (uhh?)
> and I don't know if those
On Fri, Nov 08, 2013 at 03:06:59PM +, Christoph Lameter wrote:
> On Thu, 7 Nov 2013, Frederic Weisbecker wrote:
>
> > usermodehelper works are created via workqueues, right? And workqueues are
> > an issue as
> > well for those who want CPU isolation.
>
> AFAICT usermodehelper can be called
On Thu, 7 Nov 2013, Frederic Weisbecker wrote:
> usermodehelper works are created via workqueues, right? And workqueues are an
> issue as
> well for those who want CPU isolation.
AFAICT usermodehelper can be called from a variety of contexts.
> So this looks like a more general problem than
On Thu, 7 Nov 2013, Frederic Weisbecker wrote:
usermodehelper works are created via workqueues, right? And workqueues are an
issue as
well for those who want CPU isolation.
AFAICT usermodehelper can be called from a variety of contexts.
So this looks like a more general problem than just
On Fri, Nov 08, 2013 at 03:06:59PM +, Christoph Lameter wrote:
On Thu, 7 Nov 2013, Frederic Weisbecker wrote:
usermodehelper works are created via workqueues, right? And workqueues are
an issue as
well for those who want CPU isolation.
AFAICT usermodehelper can be called from a
On Fri, 8 Nov 2013, Frederic Weisbecker wrote:
But it looks like it always end up calling a workqueue. May be I missed
something though.
Now we can argue that this workqueue seem to create kernel threads, which in
turn create other kernel thread (uhh?)
and I don't know if those inherit
On Fri, Nov 08, 2013 at 05:05:35PM +, Christoph Lameter wrote:
On Fri, 8 Nov 2013, Frederic Weisbecker wrote:
But it looks like it always end up calling a workqueue. May be I missed
something though.
Now we can argue that this workqueue seem to create kernel threads, which
in
On Fri, 8 Nov 2013, Frederic Weisbecker wrote:
I understand, but why not solving that from the workqueue affinity? We want to
solve the issue of unbound workqueues in CPU isolation anyway.
Sure if you can solve that with an unbound work queue then this patch is
not needed. Do you have a patch
On Fri, Nov 08, 2013 at 07:52:37PM +, Christoph Lameter wrote:
On Fri, 8 Nov 2013, Frederic Weisbecker wrote:
I understand, but why not solving that from the workqueue affinity? We want
to
solve the issue of unbound workqueues in CPU isolation anyway.
Sure if you can solve that
On Thu, Nov 07, 2013 at 04:43:11PM +, Christoph Lameter wrote:
> usermodehelper() threads can currently run on all processors.
> This is an issue for low latency cores. Spawnig a new thread causes
> cpu holdoffs in the range of hundreds of microseconds to a few
> milliseconds. Not good for
usermodehelper() threads can currently run on all processors.
This is an issue for low latency cores. Spawnig a new thread causes
cpu holdoffs in the range of hundreds of microseconds to a few
milliseconds. Not good for cores on which processes run that need
to react as fast as possible.
kthreadd
usermodehelper() threads can currently run on all processors.
This is an issue for low latency cores. Spawnig a new thread causes
cpu holdoffs in the range of hundreds of microseconds to a few
milliseconds. Not good for cores on which processes run that need
to react as fast as possible.
kthreadd
On Thu, Nov 07, 2013 at 04:43:11PM +, Christoph Lameter wrote:
usermodehelper() threads can currently run on all processors.
This is an issue for low latency cores. Spawnig a new thread causes
cpu holdoffs in the range of hundreds of microseconds to a few
milliseconds. Not good for cores
On Fri, 18 Oct 2013, Frederic Weisbecker wrote:
> Makes sense yeah. In fact what I'm mostly concerned about is that we should
> set the affinity of __call_usermodehelper threads through inheritance from
> a parent rather than making it setting its affinity itself. Because in the
> latter case,
>
On Fri, 18 Oct 2013, Frederic Weisbecker wrote:
Makes sense yeah. In fact what I'm mostly concerned about is that we should
set the affinity of __call_usermodehelper threads through inheritance from
a parent rather than making it setting its affinity itself. Because in the
latter case,
the
On Thu, Oct 17, 2013 at 10:50:26AM -0700, Andrew Morton wrote:
> On Thu, 17 Oct 2013 18:07:28 +0200 Frederic Weisbecker
> wrote:
>
> > Couldn't we instead make kthread children (those created with
> > kthread_create()) to inherit
> > kthread initial affinity? Currently kthread's children have
On Wed, 16 Oct 2013 22:37:52 + Christoph Lameter wrote:
> > > - /* We can run anywhere, unlike our parent keventd(). */
> > > - set_cpus_allowed_ptr(current, cpu_all_mask);
> > > + /* We can run anywhere kthreadd can run */
> >
> > This is a poor comment - it explains "what" (which was
On Thu, 17 Oct 2013, Frederic Weisbecker wrote:
> > The invocation is coming from keventd so the affinity seems to be set to
> > a different cpu before we get the thread moved.
>
> Looking at alloc_singlethread_workqueue(), it seems to create a kthread by
> using
> kthread_create(). So I guess
On Thu, 17 Oct 2013, Andrew Morton wrote:
> On Thu, 17 Oct 2013 18:07:28 +0200 Frederic Weisbecker
> wrote:
>
> > Couldn't we instead make kthread children (those created with
> > kthread_create()) to inherit
> > kthread initial affinity? Currently kthread's children have cpu_all_mask.
> > We
On Thu, 17 Oct 2013 18:07:28 +0200 Frederic Weisbecker
wrote:
> Couldn't we instead make kthread children (those created with
> kthread_create()) to inherit
> kthread initial affinity? Currently kthread's children have cpu_all_mask. We
> could change
> that behaviour. This way the initial
On Thu, Oct 17, 2013 at 03:24:36PM +, Christoph Lameter wrote:
> On Thu, 17 Oct 2013, Frederic Weisbecker wrote:
>
> > > - /* We can run anywhere, unlike our parent keventd(). */
> > > - set_cpus_allowed_ptr(current, cpu_all_mask);
> > > + /* We can run anywhere kthreadd can run */
> > > +
On Thu, 17 Oct 2013, Frederic Weisbecker wrote:
> > - /* We can run anywhere, unlike our parent keventd(). */
> > - set_cpus_allowed_ptr(current, cpu_all_mask);
> > + /* We can run anywhere kthreadd can run */
> > + set_kthreadd_affinity();
>
> If you really want your isolated CPUs to be
On Wed, Oct 16, 2013 at 02:44:28PM +, Christoph Lameter wrote:
> This is a follow on patch related to the earlier
> discussion about restricting the
> spawning of kernel threads. See https://lkml.org/lkml/2013/9/5/426
>
>
>
>
> usermodehelper() threads can currently run on all processors.
On Wed, Oct 16, 2013 at 02:44:28PM +, Christoph Lameter wrote:
This is a follow on patch related to the earlier
discussion about restricting the
spawning of kernel threads. See https://lkml.org/lkml/2013/9/5/426
usermodehelper() threads can currently run on all processors.
This is
On Thu, 17 Oct 2013, Frederic Weisbecker wrote:
- /* We can run anywhere, unlike our parent keventd(). */
- set_cpus_allowed_ptr(current, cpu_all_mask);
+ /* We can run anywhere kthreadd can run */
+ set_kthreadd_affinity();
If you really want your isolated CPUs to be
On Thu, Oct 17, 2013 at 03:24:36PM +, Christoph Lameter wrote:
On Thu, 17 Oct 2013, Frederic Weisbecker wrote:
- /* We can run anywhere, unlike our parent keventd(). */
- set_cpus_allowed_ptr(current, cpu_all_mask);
+ /* We can run anywhere kthreadd can run */
+
On Thu, 17 Oct 2013 18:07:28 +0200 Frederic Weisbecker fweis...@gmail.com
wrote:
Couldn't we instead make kthread children (those created with
kthread_create()) to inherit
kthread initial affinity? Currently kthread's children have cpu_all_mask. We
could change
that behaviour. This way
On Thu, 17 Oct 2013, Andrew Morton wrote:
On Thu, 17 Oct 2013 18:07:28 +0200 Frederic Weisbecker fweis...@gmail.com
wrote:
Couldn't we instead make kthread children (those created with
kthread_create()) to inherit
kthread initial affinity? Currently kthread's children have
On Thu, 17 Oct 2013, Frederic Weisbecker wrote:
The invocation is coming from keventd so the affinity seems to be set to
a different cpu before we get the thread moved.
Looking at alloc_singlethread_workqueue(), it seems to create a kthread by
using
kthread_create(). So I guess the
On Wed, 16 Oct 2013 22:37:52 + Christoph Lameter c...@linux.com wrote:
- /* We can run anywhere, unlike our parent keventd(). */
- set_cpus_allowed_ptr(current, cpu_all_mask);
+ /* We can run anywhere kthreadd can run */
This is a poor comment - it explains what (which was
On Thu, Oct 17, 2013 at 10:50:26AM -0700, Andrew Morton wrote:
On Thu, 17 Oct 2013 18:07:28 +0200 Frederic Weisbecker fweis...@gmail.com
wrote:
Couldn't we instead make kthread children (those created with
kthread_create()) to inherit
kthread initial affinity? Currently kthread's
On Wed, 16 Oct 2013, Andrew Morton wrote:
> > usermodehelper() threads can currently run on all processors.
> > This is an issue for low latency cores.
>
> How much of an issue? The severity of the problem is utterly unclear
> from this description.
This causes a context switch and processing
On Wed, 16 Oct 2013 14:44:28 + Christoph Lameter wrote:
> This is a follow on patch related to the earlier
> discussion about restricting the
> spawning of kernel threads. See https://lkml.org/lkml/2013/9/5/426
>
>
>
>
> usermodehelper() threads can currently run on all processors.
>
This is a follow on patch related to the earlier
discussion about restricting the
spawning of kernel threads. See https://lkml.org/lkml/2013/9/5/426
usermodehelper() threads can currently run on all processors.
This is an issue for low latency cores.
Restrict usermodehelper() threads to the
This is a follow on patch related to the earlier
discussion about restricting the
spawning of kernel threads. See https://lkml.org/lkml/2013/9/5/426
usermodehelper() threads can currently run on all processors.
This is an issue for low latency cores.
Restrict usermodehelper() threads to the
On Wed, 16 Oct 2013 14:44:28 + Christoph Lameter c...@linux.com wrote:
This is a follow on patch related to the earlier
discussion about restricting the
spawning of kernel threads. See https://lkml.org/lkml/2013/9/5/426
usermodehelper() threads can currently run on all processors.
On Wed, 16 Oct 2013, Andrew Morton wrote:
usermodehelper() threads can currently run on all processors.
This is an issue for low latency cores.
How much of an issue? The severity of the problem is utterly unclear
from this description.
This causes a context switch and processing to
44 matches
Mail list logo
