Nicholas Vinen writes:
>
>
> On Mon, 27 Mar 2000, Richard Gooch wrote:
>
> > Mate, where have you been? The day Linus lets user-space dictate what
> > goes into the kernel is the day hell freezes over. If you want a patch
> > to go into the kernel, you need to convince him it's a good idea.
> > Adding a dependency in user-space, expecting it to "force his hand",
> > will not help. It will probably just piss him off. Or make him laugh.
>
> OK, well, can any of these problems that are being discussed be
> fixed by changing/reimplementing POSIX threads? Would it help to
> boost the priority of the manager thread to realtime? Would it help
> to change the way the inter-thread communication works from a pipe
> to a more low level mechanism?
No: it's not a problem with the LinuxThreads implementation, it's a
problem of lack of kernel support to efficiently implement
POSIX-compliant pthreads.
No: the problem is round-trip communication between the manager and
other threads. RT priorities won't help.
No: pipes are just fine and very efficient. But use them enough and it
will hurt.
The problem is too many context switches and syscalls. And before you
ask: no, speeding them up isn't an option. Even if you shave off a bit
of time here and there, the fundamental problem remains: we're doing
too much of them just for a simple thread create. A plain clone(2) is
very fast, and we want pthread_create(3) to be as good.
> In fact is there any reason that when you do pthread_create, it
> doesn't just do a clone() right there? It has to clone, change
> priority (which you need the permission to do anyway, right?) and
> then jump off to the specified address..
To be POSIX compliant, you have to handle process ID's properly,
signal handling and so on. To get all this right requires a lot of
context switching and syscalls.
> Can someone explain why this had to be done in such a roundabout
> manner so that I (we) understand the issues and thus know better how
> this situation could be fixed?
Because the kernel doesn't make this easy. The kernel has the concept
of "tasks", which don't map well to POSIX threads. The kernel doesn't
distinguish between "processes" and "threads" like POSIX does.
Everything is just a task. Tasks can share some things (FS, files,
VM), but they can't (yet) share PIDs (probably never), signal queues
and other things required for POSIX compliance.
And to make the kernel POSIX compliant could mean that we have a less
efficient scheduler, or would otherwise complicate operations which
are now simple. Also, there is a view here that the POSIX semantics
are not really that useful. The native Linux semantics are equally
useful, and have the advantage of being an efficient implementation.
You could probably write a native Linux threads library (lthread_*()
anyone?) which was just as easy to use and powerful, and didn't
require buggering the kernel. So from the point of view of the kernel
community, there is reluctance to throw complex and ugly
POSIX-specific support code into the kernel, for the sake of
compliance with an ill-considered standard. Leave the problems to
user-space, and hence the performance problems people mention.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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 : Fri Mar 31 2000 - 21:00:21 EST