All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: markh@compro.net
Cc: Max Krasnyanskiy <maxk@qualcomm.com>, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>, Paul Jackson <pj@sgi.com>
Subject: Re: [PATCH sched-devel 0/7] CPU isolation extensions
Date: Fri, 22 Feb 2008 14:59:46 +0100	[thread overview]
Message-ID: <1203688786.6242.27.camel@lappy> (raw)
In-Reply-To: <47BED03A.5070707@compro.net>


On Fri, 2008-02-22 at 08:38 -0500, Mark Hounschell wrote:

> >> List of commits
> >>    cpuisol: Make cpu isolation configrable and export isolated map
> >  
> > cpu_isolated_map was a bad hack when it was introduced, I feel we should
> > deprecate it and fully integrate the functionality into cpusets. That would
> > give a much more flexible end-result.
> > 
> > CPU-sets can already isolate cpus by either creating a cpu outside of any set,
> > or a set with a single cpu not shared by any other sets.
> > 
> 
> Peter, what about when I am NOT using cpusets and are disabled in my config but
> I still want to use this?

Then you enable it?

> >>    cpuisol: Do not schedule workqueues on the isolated CPUs
> >  
> > (per-cpu workqueues, the single ones are treated in the previous section)
> > 
> > I still strongly disagree with this approach. Workqueues are passive, they
> > don't do anything unless work is provided to them. By blindly not starting them
> > you handicap the system and services that rely on them.
> > 
> 
> Have things changed since since my first bad encounter with Workqueues.
> I am referring to this thread. 
> 
> http://kerneltrap.org/mailarchive/linux-kernel/2007/5/29/97039 

Just means you get to fix those problems. By blindly not starting them
you introduce others.


  reply	other threads:[~2008-02-22 14:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-22  2:38 [PATCH sched-devel 0/7] CPU isolation extensions Max Krasnyanskiy
2008-02-22  8:36 ` Dmitry Adamushko
2008-02-22 21:04   ` Max Krasnyanskiy
2008-02-22 11:43 ` Peter Zijlstra
2008-02-22 13:38   ` Mark Hounschell
2008-02-22 13:59     ` Peter Zijlstra [this message]
2008-02-22 22:22       ` Max Krasnyanskiy
2008-02-22 22:08     ` Max Krasnyanskiy
2008-02-22 22:05   ` Max Krasnyanskiy
2008-02-23 13:05     ` Peter Zijlstra
2008-02-26  2:10       ` Max Krasnyanskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1203688786.6242.27.camel@lappy \
    --to=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markh@compro.net \
    --cc=maxk@qualcomm.com \
    --cc=mingo@elte.hu \
    --cc=pj@sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.