lkml.org 
[lkml]   [2011]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH v3 7/10] workqueue: add WQ_IDLEPRI
On Thu, 26 May 2011 11:38:08 +0200
Tejun Heo <tj@kernel.org> wrote:

> Hello, KAMEZAWA.
>
> On Thu, May 26, 2011 at 02:30:24PM +0900, KAMEZAWA Hiroyuki wrote:
> > When this idea came to me, I wonder which is better to maintain
> > memcg's thread pool or add support in workqueue for generic use. In
> > genral, I feel enhancing genric one is better...so, wrote this one.
>
> Sure, if it's something which can be useful for other users, it makes
> sense to make it generic.
>
Thank you for review.


> > Index: memcg_async/include/linux/workqueue.h
> > ===================================================================
> > --- memcg_async.orig/include/linux/workqueue.h
> > +++ memcg_async/include/linux/workqueue.h
> > @@ -56,7 +56,8 @@ enum {
> >
> > /* special cpu IDs */
> > WORK_CPU_UNBOUND = NR_CPUS,
> > - WORK_CPU_NONE = NR_CPUS + 1,
> > + WORK_CPU_IDLEPRI = NR_CPUS + 1,
> > + WORK_CPU_NONE = NR_CPUS + 2,
> > WORK_CPU_LAST = WORK_CPU_NONE,
>
> Hmmm... so, you're defining another fake CPU a la unbound CPU. I'm
> not sure whether it's really necessary to create its own worker pool
> tho. The reason why SCHED_OTHER is necessary is because it may
> consume large amount of CPU cycles. Workqueue already has UNBOUND -
> for an unbound one, workqueue code simply acts as generic worker pool
> provider and everything other than work item dispatching and worker
> management are deferred to scheduler and the workqueue user.
>
yes.

> Is there any reason memcg can't just use UNBOUND workqueue and set
> scheduling priority when the work item starts and restore it when it's
> done?

I thought of that. But I didn't do that because I wasn't sure how others
will think about changing exisitng workqueue priority...and I was curious
to know how workqueue works.

> If it's gonna be using UNBOUND at all, I don't think changing
> scheduling policy would be a noticeable overhead and I find having
> separate worker pools depending on scheduling priority somewhat silly.
>
ok.

> We can add a mechanism to manage work item scheduler priority to
> workqueue if necessary tho, I think. But that would be per-workqueue
> attribute which is applied during execution, not something per-gcwq.
>

In the next version, I'll try some like..
==
process_one_work(...) {
.....
spin_unlock_irq(&gcwq->lock);
.....
if (cwq->wq->flags & WQ_IDLEPRI) {
set_scheduler(...SCHED_IDLE...)
cond_resched();
scheduler_switched = true;
}
f(work)
if (scheduler_switched)
set_scheduler(...SCHED_OTHER...)
spin_lock_irq(&gcwq->lock);
}
==
Patch size will be much smaller. (Should I do this in memcg's code ??)
Thank you for your advices.

Thanks,
-Kame




\
 
 \ /
  Last update: 2011-05-26 12:39    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site