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

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 19:27:43 +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 7/7] sched: implement try_to_wake_up_local()

Hello,

On 12/07/2009 05:56 PM, Peter Zijlstra wrote:
> OK, so you fork and wakeup a new thread when an existing one goes to
> sleep, but do you also limit the concurrency on wakeup?
>
> Otherwise we can end up with say 100 workqueue tasks running, simply
> because they all ran into a contended lock and then woke up again.

Yes, the total number of workers is limited.

> Where does that fork happen? Having to do memory allocations and all
> that while holding the rq->lock doesn't seem like a very good idea.

There always is guaranteed to be at least one idle worker and when the
last running worker goes to sleep, one idle worker is woken up which
assumes the role of manager which if necessary forks another worker,
so all that happens under rq->lock is waking up another worker.

> What happens when you run out of memory and the workqueue progress is
> needed to get free memory?

That's when the "rescuer" workers kick in.  All workqueues which might
be used during allocation paths are required to have one.  When
manager fails to fork a new worker, it summons the rescuers.  They
migrate to the distressed cpu and processes only the works from their
specific workqueues thus guaranteeing forward progress.

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/