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: <alpine.LFD.2.01.0910011207180.6996@localhost.localdomain>
Date:	Thu, 1 Oct 2009 12:11:23 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Avi Kivity <avi@...hat.com>
cc:	Ingo Molnar <mingo@...e.hu>,
	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 Thu, 1 Oct 2009, Avi Kivity wrote:
> 
> 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).

Ok, see the email I just sent out.

And I don't think we want a new notifier - mainly because I don't think we 
want to walk the list four times (prepare, out, in, final - we need to 
make sure that these things nest properly, so even if "in" and "final" 
happen with the same state, they aren't the same, because "in" only 
happens if "out" was called, while "final" would happen if "prepare" was 
called)

So it would be better to have separate lists, in order to avoid walking 
the lists four times just because there was a single notifier that just 
wanted to be called for the inner (or outer) cases.

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

This is what the whole next-gen AIO was supposed to do with the 
threadlets, ie avoid doing a new thread if it could do the IO all cached 
and without being preempted. 

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