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 09:56:39 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Tejun Heo <tj@...nel.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()

On Mon, 2009-12-07 at 09:50 +0100, Peter Zijlstra wrote:
> On Mon, 2009-12-07 at 12:26 +0900, Tejun Heo wrote:

> > Hmmm... it was intentional as, before this patch, there's no
> > try_to_wake_up_local() so it was strange to mention it in the comment.
> > I can move the comments but I don't think it's particularly better
> > that way.
> 
> /me reads the comments and goes ah!
> 
> OK, maybe you've got a point there ;-)

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.

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.

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

--
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/