OpenBSD Journal

rthreads code comitted

Contributed by marco on from the smp-usefulness dept.

Many people submitted the following:

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)

Comments
  1. Comments

    1. By Anonymous Coward (195.224.109.30) on

      it certainly is an interesting approach

  2. By Anonymous Coward (195.224.109.30) on

    In the follow-up post, there is reference to some code that implements rfork_thread and tas routines on PowerPC.
    Has this code been committed ?
    I am checking src, but it might take a while

    Comments

    1. By phessler (69.12.168.114) on

      yes, its in.

  3. By Anonymous Coward (65.198.20.164) on

    Anyone have a non-developer's explanation of what rthreads are, what they do, how they interact with applications/kernel, and how rthreads compare to the threading implementation in other OS's such as Linux, FreeBSD, DragonFlyBSD, NetBSD, etc.? Basically, a dumbed down explanation for non-developers would be greatly appreciated. Thanks!

    Comments

    1. By tedu (69.12.168.114) on

      have you read the paper? it was an attempt to be a semi-technical explanation/comparison.

      if you still don't understand, then the very short answer is "simpler".

      Comments

      1. By Anonymous Coward (203.28.159.136) on

        I read the paper.
        Am I to understand that context switches between rthreads have the same overhead as context switches between normal processes?

        Comments

        1. By tedu (69.12.168.114) on

          yes. it's possible to optimize this, but until you have demonstrated it's a problem, i'm inclined to work on other problems. :)

      2. By Anonymous Coward (24.126.56.226) on

        Yes, I read the paper and it was actually somewhat digestable. Although, the paper really didn't do a comparison with the other BSD's (FreeBSD, DragonFlyBSD) other than mentioning that FreeBSD uses scheduler activations, which I still don't know if they're good or bad. From the paper, I gathered that SA was good but complicated. I'm not sure if that's a correct conclusion.

        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

        1. By Anonymous Coward (203.28.159.135) on

          With userspace threading, a threaded application uses the timeslice of one process. This process' timeslice is shared among each thread in the application. Each thread in the multithreaded application is scheduled less often than an equivalently prioritised process elsewhere. Essentially, there are two schedulers - the kernelspace one, and the one in the threading library.

          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.

        2. By tedu (71.139.175.127) on

          mostly correct. to the end user, there are two things you will notice. multithreaded apps actually appear to act like multithreaded apps (one thread can work while another is waiting for i/o), and cpu bound threads can take advantage of smp.

          Comments

          1. By Anonymous Coward (80.65.225.229) on

            By the way, could this be used by the kernel himself to take advantage of SMP, for heavy "kernel-land" operations (like spreading IPsec flows enc/dec computation or pf ruleset evaluations accros the CPUs) ?

            Or is it only usable for userland operations ?

        3. By tedu (71.139.175.127) on

          oh, and wrt ht, we don't really take advantage of it. on some systems, the virtual processor shows up as a cpu1, which means we could potentially use it, but the scheduler doesn't really know that it's better to run 2 threads from the same process at the same time, so it's just as likely to schedule 2 completely different processes.

          i think hyperthreading is mostly hype and really doesn't improve performance. notice that intel is now moving to dual core without hyperthreading.

          Comments

          1. By Marco Peereboom (67.64.89.177) marco@peereboom.us on http://www.peereboom.us

            Ted is right, HT is hype and only provides theoretical speed increases. In micro-benchmarks the performance improvement can be "meassured" however in the real world it is unlikely to make any positive impact.

            Comments

            1. By Not DJB (216.220.116.154) on

              > Ted is right, HT is hype and only provides theoretical speed increases. In
              > 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.

          2. By Anonymous Coward (24.126.56.226) on

            So Itel is moving away from HyperThreading, but what about Sun's Niagra CPU? That does multiple threads at a time (8 cores with 4 threads each, or something like that).

            Comments

            1. By tedu (69.12.168.114) on

              meh. don't have one.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]