KSE Progress On FreeBSD SMP Environment

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."

Comments

More Power to you

[Anonymous Coward]

This is great, and advances all of the *BSDs if it works out.

Threads in top

[cant_get_a_good_nick]

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

[shlong]

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.