linux-kernel - Re: [PATCH 03/19] scheduler: implement workqueue scheduler class

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]

Message-ID: <4AC4FC47.4010405@redhat.com>
Date:	Thu, 01 Oct 2009 21:00:23 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Tejun Heo <tj@...nel.org>, jeff@...zik.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	jens.axboe@...cle.com, rusty@...tcorp.com.au,
	cl@...ux-foundation.org, dhowells@...hat.com, arjan@...ux.intel.com
Subject: Re: [PATCH 03/19] scheduler: implement workqueue scheduler class

On 10/01/2009 08:48 PM, Ingo Molnar wrote:
> We could do what Avi suggested: not use scheduler classes at all for
> this (that brings in other limitations like lack of p->policy freedom),
> but use the existing preempt-notifications callbacks.
>
> They are per task - we would simply make preempt notifiers
> unconditional, i.e. remove CONFIG_PREEMPT_NOTIFIERS and make it all
> unconditional scheduler logic.
>
>    

Sure, but it would mean that we need a new notifier.  sched_out, 
sched_in, and wakeup (and, return to userspace, with the new notifier).

btw, I've been thinking we should extend concurrency managed workqueues 
to userspace.  Right now userspace can spawn a massive amount of 
threads, hoping to hide any waiting by making more work available to the 
scheduler.  That has the drawback of increasing latency due to 
involuntary preemption.  Or userspace can use one thread per cpu, hope 
it's the only application on the machine, and go all-aio.

But what if we added a way for userspace to tell the kernel to fork off 
threads when processing power and work to do are both available?  The 
scheduler knows when there is processing power, and an epoll fd can tell 
it when there is work to do.  So the scheduler will create threads to 
saturate the processors, if one of them waits for I/O the scheduler 
forks off another one until all queues are busy again.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

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