[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1203688786.6242.27.camel@lappy>
Date: Fri, 22 Feb 2008 14:59:46 +0100
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: markh@...pro.net
Cc: Max Krasnyanskiy <maxk@...lcomm.com>, Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>, Paul Jackson <pj@....com>
Subject: Re: [PATCH sched-devel 0/7] CPU isolation extensions
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists