public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: tglx@linutronix.de, mingo@elte.hu, avi@redhat.com, efault@gmx.de,
	rusty@rustcorp.com.au, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/7] sched: implement force_cpus_allowed()
Date: Mon, 07 Dec 2009 13:34:27 +0900	[thread overview]
Message-ID: <4B1C85D3.3080401@kernel.org> (raw)
In-Reply-To: <1259923381.3977.1934.camel@laptop>

Hello, Peter.

On 12/04/2009 07:43 PM, Peter Zijlstra wrote:
>>> force_cpus_allowed() will be used for concurrency-managed workqueue.
>>
>> Would still like to know why all this is needed.
> 
> That is, what problem do these new-fangled workqueues have and why is
> this a good solution.

This is the original RFC posting of cmwq which includes the whole
thing.  I'm a few days away from posting a new version but the usage
of force_cpus_allowed() remains the same.

  http://thread.gmane.org/gmane.linux.kernel/896268/focus=896294

There are two tests which are bypassed by the force_ variant.

* PF_THREAD_BOUND.  This is used to mark tasks which are bound to a
  cpu using kthread_bind() to be bound permanently.  However, new
  trustee based workqueue hotplugging decouples per-cpu workqueue
  flushing with cpu hot plug/unplugging.  This is necessary because
  with cmwq, long running works can be served by regular workqueues,
  so delaying completion of hot plug/unplugging till certain works are
  flushed isn't feasible.  So, what becomes necessary is the ability
  to re-bind tasks which has PF_THREAD_BOUND set but unbound from its
  now offline cpu which is coming online again.

* cpu_active() test.  CPU activeness encloses cpu online status which
  is the actual on/offline state.  Workqueues need to keep running
  while a cpu is going down and with cmwq keeping workqueues running
  involves creation of new workers (it consists part of
  forward-progress guarantee and one of cpu down callbacks might end
  up waiting on completion of certain works).

  The problem with active state is that during cpu down, active going
  off doesn't mean all tasks have been migrated off the cpu, so
  without a migration interface which is synchronized with the actual
  offline migration, it is difficult to guarantee that all works are
  either running on the designated cpu if the cpu is online or all
  work on other cpus if the cpu is offline.

  Another related problem is that there's no way to monitor the cpu
  activeness change notifications.

Thanks.

-- 
tejun

  reply	other threads:[~2009-12-07  4:34 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-02  3:56 [PATCHSET tip/sched/core] sched: concurrency managed workqueue related sched patches Tejun Heo
2009-12-02  3:56 ` [PATCH 1/7] sched: revert 498657a478c60be092208422fefa9c7b248729c2 Tejun Heo
2009-12-02 10:42   ` [tip:sched/core] sched: Revert 498657a478c60be092208422fefa9c7b248729c2 tip-bot for Tejun Heo
2009-12-02  3:56 ` [PATCH 2/7] sched: rename preempt_notifiers to sched_notifiers and refactor implementation Tejun Heo
2009-12-02  3:56 ` [PATCH 3/7] sched: refactor try_to_wake_up() Tejun Heo
2009-12-02  9:05   ` Mike Galbraith
2009-12-02  9:51     ` Tejun Heo
2009-12-02 10:10       ` Mike Galbraith
2009-12-02 10:14         ` Tejun Heo
2009-12-02 11:01           ` Peter Zijlstra
2009-12-03  6:11   ` [PATCH UDPATED " Tejun Heo
2009-12-02  3:56 ` [PATCH 4/7] sched: implement force_cpus_allowed() Tejun Heo
2009-12-04 10:40   ` Peter Zijlstra
2009-12-04 10:43     ` Peter Zijlstra
2009-12-07  4:34       ` Tejun Heo [this message]
2009-12-07  8:35         ` Peter Zijlstra
2009-12-07 10:34           ` Tejun Heo
2009-12-07 10:54             ` Peter Zijlstra
2009-12-07 11:07               ` Tejun Heo
2009-12-08  8:41                 ` Tejun Heo
2009-12-08  9:02                   ` Peter Zijlstra
2009-12-08  9:12                     ` Tejun Heo
2009-12-08 10:34                       ` Peter Zijlstra
2009-12-08 10:38                         ` Peter Zijlstra
2009-12-08 11:26                           ` Tejun Heo
2009-12-08 11:24                         ` Tejun Heo
2009-12-08 11:48                           ` Peter Zijlstra
2009-12-08 11:56                             ` Tejun Heo
2009-12-08 12:10                               ` Peter Zijlstra
2009-12-08 12:23                                 ` Tejun Heo
2009-12-08 13:35                                   ` Peter Zijlstra
2009-12-09  5:25                                     ` Tejun Heo
2009-12-09  7:41                                       ` Peter Zijlstra
2009-12-09  8:03                                         ` Tejun Heo
2009-12-02  3:56 ` [PATCH 5/7] sched: make sched_notifiers unconditional Tejun Heo
2009-12-02  3:56 ` [PATCH 6/7] sched: add wakeup/sleep sched_notifiers and allow NULL notifier ops Tejun Heo
2009-12-02  3:56 ` [PATCH 7/7] sched: implement try_to_wake_up_local() Tejun Heo
2009-12-03  6:13   ` [PATCH UPDATED " Tejun Heo
2009-12-04 10:47     ` Peter Zijlstra
2009-12-07  3:31       ` Tejun Heo
2009-12-04 10:44   ` [PATCH " Peter Zijlstra
2009-12-07  3:26     ` Tejun Heo
2009-12-07  8:50       ` Peter Zijlstra
2009-12-07  8:56         ` Peter Zijlstra
2009-12-07 10:27           ` Tejun Heo
2009-12-08  8:53             ` Peter Zijlstra
2009-12-08  9:16               ` Tejun Heo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B1C85D3.3080401@kernel.org \
    --to=tj@kernel.org \
    --cc=avi@redhat.com \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox