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. Read more at FreeBSDForums.
KSE Progress on FreeBSD SMP Environment
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
14 Comments
2003-06-25 3:33 pm
2003-06-25 5:49 pm
A hybrid approach, the sort Sun has moved away with in Solaris 9 for performance reasons. Linux too, NPTL over LGPT (was that what it was called?) for performance reasons. Still, this outa be better then what they currently use. I wish them luck. Can’t wait until FBSD 5 is complete, benchmarks with it and Solaris 9 and Linux 2.6 outa be very, very interesting.
As a FreeBSD user and Malaysian, I feel proud to see this new development of KSE. I’m waiting the KSE project to be completed and implemented in 5.x.
FreeBSD has now also a (experimental) 1:1 threads implementation similar to what Solaris 9 and Linux use. You have the choice! libmap.conf allows you to choose different threading libraries for different applications. When they mature a bit it will be very interesting to do performance comparsions on the same operating system between these different threading implementations.
Free software power!
The hybrid approach should function better in practice. The hybrid has most of the advantages of both and few of the disadvantages of either. It seems a matter of putting theory in practice, and that’s something BSD has traditionally been good at.
“The hybrid has most of the advantages of both and few of the disadvantages of either.”
Sun once said the same thing, until they found costumers were using the 1:1 approach far more often for performance reasons. Now Solaris 9 ships with only it. Still, if FBSD can pull it off then kick ass. I wish them luck.
System jobs should always run in 1:1 so system task can be taken care of (IO, Cache control, Virtual Memory, …).
If you’re running a system like mine at work which normally has around 1600 jobs running on all day, then user jobs should be scheduled using 1:N. This allows the system priorties jobs on a per job bases. If the user land is running 1:1, then each thried in a a job is treated as a new program. If my job is not running fast enough for me, I just create a new thried and I get more of the CPUs time; this is the wrong approch when the number of jobs in creases and makes coharent job scheduling next to imposiable.
Please not that Linux kernel is being readied for workstations and desktops (per Linus). Thus the 1:1 job scheduler is all that is needed since most desktops seldom run more then about 100 jobs (deamons and damons count).
The man advantages to 1:N is not noticed until you move into a more batch type system. IE: reports and long running tasks are passed off into a background task leaving the user free to do something else. Since each background task is handled by a program, this would be the same so doing a spawn() in Linux. If you run a larger server with 200 users and allow each user to spawn() 10 reports, then expect the system to become so unresponse as to be unusedable. In a batch system, you don’t directly spawn() the report program, but instead submit a request to run the program to a scheduling deamon which will then allow a limited number of reports to run; this lets the system administator control the number of programs running and lets him keep the interactive programs running with a reasonable response time.
Now, all FreeBSD needs is a scheduling deamon and someone to convince the programmers to use it. Just think, a FreeBSD server with several hundred dumb terminals that is still responsive to the users while the CPUs are maxed out at 100%.
The hybrid approach should function better in practice. The hybrid has most of the advantages of both and few of the disadvantages of either.
And yet Sun, who had an MxN implementation for _years_, ditched that approach when they found that it was nigh impossible to properly debug, and instead replaced it with a 1:1 implementation which actually outperformed the MxN one.
And here’s Ingo Molnar’s (one of the two programmers of Linux’ NPTL) somewhat in-depth thoughts on the issue:
http://marc.theaimsgroup.com/?l=linux-kernel&m=103284879216107&w=2
Just because Sun and Linux have failed in their attempt to create this hybrid does not neccesarily indicate that FreeBSD will.
Linux hackers will always try to say such solution is too complex to do any good. This is the classic Linux lie for all solutions until they are able to do the same thing. The said truth is that Linux lacks the central organization to undergo such a drastic change in the kernel. Linux works only in evolutionary terms. It will never be able to undergo such a complex project that radically changes the entire kernel because of it’s distributed development approach. On the otherhand, FreeBSD has a very strong central administration, and has been able to redesign their entire kernel around this and has been able to make everyone work with these changes in mind.
In the case of Sun, Sun is limited to live in the business world. They definately acknowledged that there is a definite advantage to this hybrid approach, and this is the reason that they spent so much R&D and effort trying to do it. But due to business, fiscal, and competitive pressures, they were forced to adopt the simpler approach. They could not afford to be where FreeBSD is and still compete with HP and Sun on 100 cpu systems. They were forced to adopt the simpler method and like any other company in their shoes would, advertise it as the better solution.
I absolutely agree. Linux kernel development does not occur with planning. And Linus himself bashed such efforts once:
http://kerneltrap.org/node.php?id=11&PHPSESSID=86f9e54ec7cecc5d6fe1…
So he essentially believes if you do any planning you’re doomed.
Surely IBM, SGI, Red Hat etc. probably are more organized and commit code that is planned in advance. But usually linux development works in terms of successive hacks. Whereas FreeBSD has potential to bring this about. And if they believe M:N model will theoretically perform better and invest in that project with code, I have good reasons to believe it would. Because BSD guys know what they’re doing. No linux bashing intended but that’s the case.
The said truth is that Linux lacks the central organization to undergo such a drastic change in the kernel. Linux works only in evolutionary terms. It will never be able to undergo such a complex project that radically changes the entire kernel because of it’s distributed development approach.
It seems you’re not aware of the fact that Linux ALREADY HAS a M:N posix threading implementation!:
http://www-124.ibm.com/pthreads/
However, development stopped once it was clear that NPTL was superior:
http://www-124.ibm.com/pthreads/docs/announcement
The rest of your post is a combination of wishful thinking and utter rubbish.