On Tue, 25 Jan 2000, Dan Creswell wrote:
...
> With respect to having a decent Java implementation, it would appear
> desirable that the kernel provide some support for many-to-many mapping
> of threads. What do you think? Is it worth doing? If not, why not?
there is no real performance argument, since volanomark-loopback is quite
unlike all known real applications. even a massively-threaded app will
have most threads blocked on IO, and/or compute bound. in the former case,
they won't be on the runqueue, and in the latter, they won't be triggering
the scheduler often enough to matter.
> Basically, I'd like to pull the discussion away from the benchmarking
> thing and talk architecture.
I suggest you do work on it off linux-kernel, then post when you have
positive results, since there's really no motivation (yet) for changing
the kernel. in particular, I'd encourage you to read about Mach "scheduler
activations". something like SA's would permit the kernel and a user-level
scheduler to cooperate in a probably valuable way.
the main design question is: "what support would a smart user-level thread
package need from the kernel?" perhaps nothing more than a means of calling
up to the thread package when one of its threads does something blocking,
since that has always been the weak point of user-level threading. normal
kinds of locking could then be done without involving the kernel, which
is obviously a major win.
regards, mark hahn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:13 EST