Hi,
On Tue, Sep 10, 2013 at 9:47 AM, Mike Galbraith <[email protected]> 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 <[email protected]> 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=? highlatency_cpus=? > > > > > > > First off, thank you for doing this. It is very useful :-) > > > > Currently if one wishes to run a single task on an isolated CPU with > > 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 parameter, perhaps even the existing isolcpus? > > isolcpus is supposed to go away, as cpusets can isolate CPUs, and can > turn off load balancing. > And I'm all for that. I think cpusets is a much more elegant solution. But... AFAIK currently cpusets cannot migrate timers that were registered on a cpu prior to it being isolated via cpuset, designate RCU off loaded CPUs or sets cpus as full nohz capable, or - it seems from this patch, keep off certain kernel thread off a cpu. This is no fault of cpusets, but it still means there are work loads that it can't support at this time. So long as we must have a kernel boot option, I prefer to have one and not four of them. Think of it this way - when we put all these capabilities into cpusets, we'll have just one kernel option to kill and not four. Does that makes sense? Gilad > > -Mike > -- Gilad Ben-Yossef Chief Coffee Drinker [email protected] Israel Cell: +972-52-8260388 US Cell: +1-973-8260388 http://benyossef.com "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
