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 s
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 is
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 solv
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 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
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 inher
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 jus
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 core
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 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 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 c
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 utterl
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 th
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 kthr
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 */
> > > + set
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 u
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, 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
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
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 co
22 matches
Mail list logo
