Auto-Adaptive scheduler - Final chapter ( the numbers ) ...

[Larry McVoy]

: Larry McVoy wrote:
: > : _If_ we see that low RQ applications don't switch much, then we can
: > : assert that low RQ applications aren't adversely affected by the patch.
: > 
: > Huh?  What about I/O servers?  FTP, Web, etc?  Are they not low RQ and 
: > frequently switching applications?  Yes, they are.
: 
: If they are frequently switching, there must be several processes to
: switch 

No.  You can have this with one process that is blocking on I/O.  It happens
all the time.  Think of a relatively low bandwidth network connection.

: The thing is, here it's not obviously a user level mistake.  Linux
: threaded applications work the way they do because clone() provides
: threading facilities and there is no mechanism to help user-level
: context switching.

In my experience, if there is a need for user level context switching,
something is badly broken - either the scheduler or the application or
both.  I've seen this where people were thread-minded enough to allocate
a thread per logical operation (Sun once had all I/O implemented this
way, over my screams of protest that allocationg a 16K stack to shepard
an 8K page out the door was insane; they didn't listen, did it anyway,
figured out what crazy thing it was, and never shipped that kernel).

You really shouldn't be allocating lots and lots of threads, it just never
makes sense unless you have lots and lots of processors.

: Then IBM would have nothing to bitch about -- their Java context
: switches would be _really_ fast and everything would run with equivalent
: performance.

This is just wall papering over a bad benchmark.

: That way threads can continue to use kernel facilities with the same ease
: of use as clone(), but if they block, it's easy for the application
: level to get on with something else.  Without having to have lots of
: kernel level threads runnable -- which is less efficient anyway.

Have you ever maintained such a system?  It really is a pain to have
both user level and kernel level semantics.  You get into all sorts of
nasty issues which need to be solved.  I much prefer the cleanliness of
the clone()/rfork() model.   I don't care if apps want to build wacky
stuff on top of that model, but I'd hate to see that wacky stuff being
part of a supported user level API.  Those sorts of things tend to be
a real support nightmare over the years.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/