Contributed by marco on from the smp-usefulness dept.
As seen on this tech@ post, Ted Unangst as committed a first version of the rthread code.
Though not completely enabled right now (the RTHREADS option will have to be included in the kernel config file) it's going to be interesting to put it under test, especially on MP machines.
(Comments are closed)
By sthen (81.168.66.229) on
Comments
By Anonymous Coward (195.224.109.30) on
By Anonymous Coward (195.224.109.30) on
Has this code been committed ?
I am checking src, but it might take a while
Comments
By phessler (69.12.168.114) on
By Anonymous Coward (65.198.20.164) on
Comments
By tedu (69.12.168.114) on
if you still don't understand, then the very short answer is "simpler".
Comments
By Anonymous Coward (203.28.159.136) on
Am I to understand that context switches between rthreads have the same overhead as context switches between normal processes?
Comments
By tedu (69.12.168.114) on
By Anonymous Coward (24.126.56.226) on
From what I read, it's a 1:1 threading implementation as opposed to FreeBSD's M:N implementation (whatever that means). I understand that to be 1 kernel thread for every 1 user thread. I understand that user threads are threads created by applications in user space (i.e. MySQL), as oppsed to kernel threads that are spawned/created in the kernel. Is this correct?
I'm assuming that there needs to be 1:1 mapping because it takes 1 kernel thread to handle/execute/do whatever with 1 user thread? Is that how it works?
I also read a bit about the scheduling. From what I understand, if one thread is busy (waiting for I/O or something) then it should be put aside to let another thread execute. Is that right? I don't think I fully understood how that worked. Also, how is this handled on CPU's that are capable of handling multiple threads at once (i.e. HyperThreading)?
From what you just said, I guess the bottom line is that it's a much simpler implementation. I guess from a user standpoint, I'm wondering "will this make applications that make use of threading run any faster?" I guess from a user standpoint that's pretty much the bottom line.
Comments
By Anonymous Coward (203.28.159.135) on
With rthreads, a thread is treated like a process (albeit with a shared adress space). So, each thread in a multithreaded app gets scheduled just as often as any other process (assuming no prioritisation).
You could say that it's fairer on each thread, in terms of cpu time.
In interactive multithreaded applications like mozilla, you can notice the affects of the userspace threading library. There is more latency in doing something (e.g. opening a page in a new tab) than is expected, because the process which handles the new job is scheduled onto the cpu less often.
By tedu (71.139.175.127) on
Comments
By Anonymous Coward (80.65.225.229) on
Or is it only usable for userland operations ?
By tedu (71.139.175.127) on
i think hyperthreading is mostly hype and really doesn't improve performance. notice that intel is now moving to dual core without hyperthreading.
Comments
By Marco Peereboom (67.64.89.177) marco@peereboom.us on http://www.peereboom.us
Comments
By Not DJB (216.220.116.154) on
> micro-benchmarks the performance improvement can be "meassured" however
> in the real world it is unlikely to make any positive impact.
I recently did some test with a machine that does as many qmail deliveries as it can. This is FreeBSD 4.11, but I would assume you could extrapolate to other OSes and non-threaded apps. I had two comparisons to make:
HT vs. no HT on the same P4 2.4
above vs. older dual 1GHz PIII
What did I find? Less than half the deliveries with HT disabled. The PIII performed similarly to the non-HT case on the P4. I still do not truly understand how HT works, but one writeup I saw mentioned that even with a bunch of non-threaded forking apps, the context switching overhead was way lower with HT. Why? No idea, but qmail likes HT on FreeBSD at least...
Sorry for the slight OT WRT OS.
By Anonymous Coward (24.126.56.226) on
Comments
By tedu (69.12.168.114) on