On Tue, 2013-09-10 at 09:59 +0300, Gilad Ben-Yossef wrote: > Hi, > > > On Tue, Sep 10, 2013 at 9:47 AM, Mike Galbraith <bitbuc...@online.de> 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 <c...@linux.com> 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?
Hammering on the wrong spot makes removing isolcpus take longer, and adds up to more hammering in the long run, no? Hearing you mention isolcpus, I just thought I should mention that it wants to go away, so might not be the optimal spot for isolation related tinkering. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
