Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems

KSE Progress On FreeBSD SMP Environment 60

Posted by Hemos from the threads-for-the-world dept.
Dan writes "This is a significant milestone to be shared with everyone! Khairil Yusof reports that libkse is now running quite well on his FreeBSD 5.1+ current based SMP system. He has tested a bunch of apps on his system, taking the approach of enabling kse one app at a time. He reports a current uptime of 23hrs with these apps running with libkse.so.1, and basically a usable Gnome 2.2 desktop environment. He says that with recent updates, you can now see the threads with top(8). Kernel Scheduler Entities (KSE), is a kernel-supported threading system similar in design to Scheduler Activations [Anderson, et. al.]. It strikes a balance between user-level (1:N) and kernel-level (1:1) threading models, giving most of the advantages of both, and few of the disadvantages of either."
This discussion has been archived. No new comments can be posted.

KSE Progress On FreeBSD SMP Environment More

KSE Progress On FreeBSD SMP Environment

Comments Filter:

  • More Power to you (Score:4, Insightful)

    by Anonymous Coward on Monday June 23, 2003 @06:31AM (#6272076)
    This is great, and advances all of the *BSDs if it works out.

  • Testsuit and benchmark (Score:5, Interesting)

    by rapiere ( 235287 ) on Monday June 23, 2003 @07:53AM (#6272448) Homepage
    KSE seems really an interesting implementation in FreeBSD as well as the process to integrate it in the kernel/userland.

    LIBMAP permits to cleanly test it on your system (5.1-RELEASE or -CURRENT) one application at a time (you redefine libraries linking per application). I've tried it with mozilla 1.4b for more than a week now without any trouble.

    However I wonder about developper's testsuit and benchmarks in order to give some clues to others about how great KSE is.

    • How to enable libmap (Score:4, Informative)

      by kaeru ( 245396 ) <khairil.yusof@OPENBSDgmail.com minus bsd> on Tuesday June 24, 2003 @03:44AM (#6282379) Homepage
      To do this you need to recompile ld-elf.so.1 to support dynamic lib mapping:

      cd /usr/src/libexec/rtld-elf/

      make -DWITH_LIBMAP
      make install

      Then you need to have a libmap.conf in your /etc dir. Details of it can be accessed by reading the man pages libmap.conf(8).

      Here is a sample with mozilla firebird mapped to libkse:

      [/usr/X11R6/lib/firebird/lib/mozilla-1.4b/Mozill aF irebird-bin]
      libc_r.so.5 libkse.so.1
      libc_r.so libkse.so

      Just add more entries if you wish. You can test out whether an application is using libc_r or libkse by running ldd(8).

      Note the library mapping can be done as Scott mentions also for libthr also for 1:1 threading.

  • Threads in top (Score:4, Insightful)

    by cant_get_a_good_nick ( 172131 ) on Monday June 23, 2003 @09:35AM (#6273211)
    He says that with recent updates, you can now see the threads with top(8)

    I hope this is something you can turn off and on. One of my problems with the Linux threading model is that you see every thread as a proc, which makes it harder to administer a box. top output becomes overwhelming.

    • Re:Threads in top (Score:4, Informative)

      by Hard_Code ( 49548 ) on Monday June 23, 2003 @12:25PM (#6274764)
      Well something must have changed in recent psutils, because now 'ps' correctly collapses threads within processes when they are not active (I assume). When my site gets a hit, I see the threads expand, and once the request is served, they are collapsed back under a single process line.

      • Re:Threads in top (Score:4, Insightful)

        by shlong ( 121504 ) on Tuesday June 24, 2003 @02:56AM (#6282248) Homepage
        Well something must have changed in recent psutils, because now 'ps' correctly collapses threads within processes when they are not active (I assume). When my site gets a hit, I see the threads expand, and once the request is served, they are collapsed back under a single process line.

        The support that I added was to make the kernel return info on all threads unless it is told not to. I then changed ps(1) to tell the kernel to not return all threads unless the user specifies the -H option. I didn't modify top as it is vendor code and I haven't gotten around to tackling it yet.

        As for your observation, remember that in KSE/SA the kernel only knows about the threads that have blocked inside of it and the per-CPU scheduler activation (i.e. execution context) that it supplies to the userland scheduler (UTS). It has no knowledge of threads that the UTS creates that stay in userland. Sooo.... it is likely that you saw a thread that blocked in the kernel waiting for the socket, and then left the kernel once the socket woke up.

        Don't forget that there is also the libthr 1:1 library. That creates a kernel thread for every user thread. Since the kernel knows about every thread, ps and top will show each thread also.

        I'm incredibly pleased with all of this. I finally got around to reading the SA paper last month, and it's very cool to see KSE start to realize its potential. 5.2 and 5.3 will be very exciting releases.
    • I haven't updated 5.x in a month or so, however, this may not be how the same as what you're thinking.

      Take MacOS X's top output for example:
      PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
      14055 mozilla-bi 0.8% 7:18.05 12 185 803 43.3M 30.3M 56.2M 278M

      As you can see it's just a field in top that shows the # of threads under that process. I'd imagine that would be how it is done in FreeBSD as well. I could be wrong though, can anyone confirm?

      Cheers,
      -JD-

  • Comparison (Score:3, Interesting)

    by bobbozzo ( 622815 ) on Monday June 23, 2003 @06:58PM (#6279219)
    Would someone care to explain the differences/similarities between this and the new Linux (2.5) threads implementation?

    TIA

    • Re:Comparison (Score:4, Informative)

      by Anonymous Coward on Tuesday June 24, 2003 @03:12AM (#6282300)
      Linux (2.5) implements a 1:1 kernel threads model. KSE is a much more complex N:M threading model. FreeBSD also has brand new 1:1 kernel threads (similar to what Linux and Solaris have). You can choose (per application!!!) which threading library you like to use :-)

    • Would someone care to explain the differences/similarities between this and the new Linux (2.5) threads implementation?

      Linux has one kernel thread per thread-the-user-program-thinks-it-has ("apparent threads"). The old pthreads lib had one kernel level thread per process no matter how many apparent threads there are. The new KSE has some threads per process, but that can be far fewer then the number of apparent threads.

      Having one kernel thread per apparent thread means you don't need non-blocking k

  • KSE + SCHED_ULE (Score:3, Interesting)

    by ByTor-2112 ( 313205 ) on Thursday June 26, 2003 @09:51AM (#6302697)
    Unfortunately, the new smp-aware/optimized scheduler does not play well with KSE yet. It seems to work just fine with libthr but there are signal delivery problems with KSE that result in unkillable processes spinning endlessly. That said, it works fantastic with the old scheduler.

    FreeBSD has a number of projects that are nearing production-ready that will greatly enhance an already incredible OS!
  • Hope this becomes as stable and fast as the rest of freebsd. Way to go FreeBSD/KSE team, good job !

Slashdot Top Deals

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson

Close