linux-kernel - Re: [PATCH 4/7] sched: implement force_cpus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 07 Dec 2009 13:34:27 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	tglx@...utronix.de, mingo@...e.hu, avi@...hat.com, efault@....de,
	rusty@...tcorp.com.au, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/7] sched: implement force_cpus_allowed()

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/