[lkml]   [2014]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH] rcu: move SRCU grace period work to power efficient workqueue
Mike Galbraith <> writes:

> On Sun, 2014-02-16 at 08:41 -0800, Paul E. McKenney wrote:
>> So if there is NO_HZ_FULL, you have no objection to binding workqueues to
>> the timekeeping CPUs, but that you would also like some form of automatic
>> binding in the !NO_HZ_FULL case. Of course, if a common mechanism could
>> serve both cases, that would be good. And yes, cpusets are frowned upon
>> for some workloads.
> I'm not _objecting_, I'm not driving, Frederic's doing that ;-)
> That said, isolation seems to be turning into a property of nohz mode,
> but as I see it, nohz_full is an extension to generic isolation.
>> So maybe start with Kevin's patch, but augment with something else for
>> the !NO_HZ_FULL case?
> Sure (hm, does it work without workqueue.disable_numa ?).

[ /me returns from vacation ]

Yes, since it happens for every alloc_workqueue_attrs()

> It just seems to me that tying it to sched domain construction would be
> a better fit. That way, it doesn't matter what your isolation requiring
> load is, whether you run a gaggle of realtime tasks or one HPC task your
> business, the generic requirement is isolation, not tick mode. For one
> HPC task per core, you want no tick, if you're running all SCHED_FIFO,
> maybe you want that too, depends on the impact of nohz_full mode. All
> sensitive loads want the isolation, but they may not like the price.
> I personally like the cpuset way. Being able to partition boxen on the
> fly makes them very flexible. In a perfect world, you'd be able to
> quiesce and configure offloading and nohz_full on the fly too, and not
> end up with some hodgepodge like this needs boot option foo, that
> happens invisibly because of config option bar, the other thing you have
> to do manually.. and you get to eat 937 kthreads and tons of overhead on
> all CPUs if you want the ability to _maybe_ run a critical task or two.

Yeah, my patch only addresses the nohz_full case, but since there
doesn't seem to be any general agreemenet about the generic case, it
seems that exposing all unbound workqueues via WQ_SYSFS is the way to

Mike, looks like you may have started on that. Did it get any further?


 \ /
  Last update: 2014-02-25 09:01    [W:0.054 / U:3.800 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site