linux-kernel - Re: [RFC] observe and act upon workload parallelism: PERF_TYPE_PARALLELISM (Was: [RFC][PATCH] sched_wait

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.0911161011130.9384@localhost.localdomain>
Date:	Mon, 16 Nov 2009 10:18:59 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Stijn Devriendt <highguy@...il.com>,
	Mike Galbraith <efault@....de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrea Arcangeli <andrea@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	peterz@...radead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] observe and act upon workload parallelism: PERF_TYPE_PARALLELISM
 (Was: [RFC][PATCH] sched_wait_block: wait for blocked threads)

On Mon, 16 Nov 2009, Linus Torvalds wrote:
> 
> Think of it like a classic user-level threading package, where one process 
> implements multiple threads entirely in user space, and switches between 
> them. Except we'd do the exact reverse: create multiple threads in the 
> kernel, but only run _one_ of them at a time. So as far as the scheduler 
> is concerned, it acts as just a single thread - except it's a single 
> thread that has multiple instances associated with it.

Side note: before anybody asks why not do threads in user space to begin 
with, it's simple: IO, exceptions, and timers. All need kernel support. 

User-level threading works very well, and is usually efficient as hell. 
It's not that long since people constantly claimed that thread libraries 
in user space were much better, and tried to use complex NxM models to do 
them, exactly because user threads are so great.

But almost nobody does user-level threading now, except for specific 
languages that are built around threading. Why? It's not because they 
don't work, it's because they have a few very annoying problems that make 
them not work at all for enough situations that it gets very painful. And 
it's usually about IO and system calls, but sometimes it's about page 
faults, and sometimes it's about the pain of multiplexing that annoying 
timer signal and all the crap that involves.

So I'm suggesting that maybe we could look at doing kernel threads that do 
what user-level threading does. It sounds idiotic, and maybe it is - after 
all, traditionally one of the reasons for user-level threads is that you 
can avoid all the kernel overheads. But if we can make some really 
low-overhead "thread within a thread" model, maybe we could have close to 
the best of both worlds.

Some people really want threads for multi-CPU workloads and spreading 
things out. That's what we have now. But other loads want threads for 
entirely different reasons, like just hiding IO latencies.

			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/