[lkml]   [2009]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.


 \ /
  Last update: 2009-11-18 23:46    [W:0.075 / U:8.424 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site