Slashdot Mirror
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."
This is great, and advances all of the *BSDs if it works out.
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.
Ok, so where is the script that runs over the ports collection (also /usr/src ?) and replaces -pthread with -lpthread ? Not sure wether this will be needed for the base system, but I would imagine.
I may not have a clue, but I do have a spare alpha-machine to test.
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.
Unless I'm wrong, I am under the impression there has been a fair bit of cross-polination (sp?) between the BSDs over the years, will it continue with this and all previous SMP work for FreeBSD?
Or, to state this more clearly ('tis monday, you know), will Net/OpenBSD benefit from FreeBSD's work on SMP, including this KSE stuff?
Maybe.
I know OpenBSD has a group in a totally different project working on SMP for OpenBSD. The different BSDs have fairly different kernel internals as far as I know. It certainly wouldn't be a cut and paste job.
Skipping over the vague anecdote and pleas for "fanatics" and "addicts" to start flaming (back), here's the obvious answer:
IT WORKS FOR ME
BSD is not dying. Go look at netcraft, BSD/OS and FreeBSD are the only operating systems listed with the longest uptime. Go look at what Apache.org websites are running all FreeBSD except for two or three servers are Linux or Mac OS X (which consists like 90% FreeBSD servers).
It would have been nice for you to mention that you're using a Mac, instead of obtusely implying it (8600, BBEdit Lite).
The section of OSX that copying a file involves is not BSD-related, as I understand it. It's Mach. (People who know more about OSX than I do, feel free to pipe up.) The kernel of OSX is not very BSD-based, and most of what you're talking about (HDD access, scheduling) takes place in the kernel. (To be fair, the scheduler that FreeBSD uses was adapted from Mach.)
The 8600 (which was discontinued over a half decade ago, by the way) is not even compatible with OSX. The minimum requirement for OSX is the Beige Power Mac G3. (See Apple's requirements page.) So, I'm guessing you put in a G3 daughterboard. (Find out about the 8600 and available daughterboards at lowendmac.com.) But OSX doesn't support processor upgrade cards. (First paragraph of the requirements page.) Maybe you didn't put in an upgrade card, and are using the mach_kernel for the 604 from the Darwin project like this guy did. Either way, you're still not using a supported system.
So, you're using unsupported hardware, and a BSD-related OS in an operation that's not related to the BSD bits, and using this to say that BSD sucks. Hmmm.
I'm surprised an 8600 w/ daughterboard (which one, by the way? The 233MHz with 512k of cache?) works at all with OSX. As for why it's slow for you, I can only hypothesize, since I'm not a Mac guy. (That's right, anybody can find this stuff out with a quick google search or two!) The G3 upgrade card is going to need an L2 cache enabler. Do you have one installed? Okay, how about this idea. I'm guessing that your old, discontinued, unsupported hardware uses a bus controller (or other critical chip) that is not being programmed optimally by OSX. Why? Because the programmer writing that code knew that the chip wasn't going to be supported!
My advice is to stick to using 9.1 on your 8600. And don't generalize about BSD from your situation; it's an extreme.
I'm not sure about OpenBSD, but there's not much shared code in those areas between NetBSD and FreeBSD. On NetBSD, Bill Sommerfeld did most of the i386 SMP code, and Nathan Williams is the guy who's working on scheduler activations. SA is a M:N implementation, not much different from FreeBSD's KSE, which was developed mainly by Julian Elisher. SMPng is the work of many people, specially John Baldwin. Note that KSE is only really finished on i386, Alpha and Sparc64 are still missing some bits.
SA is not as advanced as KSE, though, but it looks very promising. AFAIK, kernel assisted threading and SMP have never been priorities for the OpenBSD people, ergo, little work has been done in those areas.
Would someone care to explain the differences/similarities between this and the new Linux (2.5) threads implementation?
TIA
Nothing to see here; Move along.
From what I understand, SMP opens all kinds of possible race conditions and other such nasty potential security holes, so OpenBSD doesn't want to implement something like this until they can be sure they can do it securely. Which may not be for a while, hard to tell.
At least mafia-owned pizzarias make excellent pizza. Compare to Bill Gates.
My advice is to stick to using 9.1 on your 8600. And don't generalize about BSD from your situation; it's an extreme.
It's a search-and-replace of an ancient troll--the original was about classic MacOS; it's been reposted as about MacOS X, and now as about BSD.
In general, keep in mind that stories in the BSD and Apple sections will always have these stock trolls (e.g., "BSD is dying," "Elegy for BSD," "Developer Laments," "Dear Apple," "Dear Fr. O'Day," etc...).
with much gayness,
Dahan, C.S.B.
I'm happy that Khairil Yusof is happy today. While the rest of us are either worrying or giggling over the imminent demise of this or that, it's good to know that someone somewhere is happy with what they have while they have it. Pity the poor fools who laugh off the inevitable and then fear it when it's their turn. They don't know what they're missing.
Sure, as soon as libkse/libthr prove their worth and the other projects find a nice clean way to weld the appropriate FreeBSD code to *BSD's code. Or maybe they'll go their own way and FreeBSD will have a change of heart and grab some *BSD threading code. Regardless, it's a good deal all around.
Is it really finished on i386? I thought they still needed to get signals to work right, which is kind of ironic because that was supposedly where some Solaris kernel developers had some trouble, according to an interview posted on Slashdot.
To do this you need to recompile ld-elf.so.1 to support dynamic lib mapping:
/usr/src/libexec/rtld-elf/
/etc dir. Details of it can be accessed by reading the man pages libmap.conf(8).
l aF irebird-bin]
cd
make -DWITH_LIBMAP
make install
Then you need to have a libmap.conf in your
Here is a sample with mozilla firebird mapped to libkse:
[/usr/X11R6/lib/firebird/lib/mozilla-1.4b/Mozil
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.
And your words betray your point. If this were true, then BSD/OS or FreeBSD would not be the only ones with the longest uptime as the values get cycled after 497 days. Fact is if your point were correct then you would see HP-UX, Linux, or Solaris up there too.
You know, under BSD (or any other Unix) you could have used the "sed" utility to do the search and replace on that file automatically with a single command, instead of deleting each occurance of "Mac" by hand and typing out "BSD" in its place in Notepad (even if you have discovered the search-and-replace facility in Notepad, you have to admit sed is much easier).
What is this guy's problem, this is the third time I have personally seen this exact same comment, most of them have been in MacOS X threads.
This guy is one sour System 7 user.
Error 407 - No creative sig found
Since someone apparently didn't read the comment I shall point out the obvious. Notice the two words "recent releases." How many of these people are running recent releases? Especially if they have uptimes this long, I think you can figure it out. These aren't my words anyway, these are netcrafts words. Read the FAQ. My point is correct but you totally misunderstood the point. The reason you don't see those OS's up there is because they DO reset after 497 days while older BSD's DO NOT do this. How is HP-UX, Linux, or Solaris supposed to show up if they never get above 497 days?
SCO is running Linux.
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 !
You're a genuine stupid fuck aren't you? It's official, the slashdot community is filled with braindead retards.
[eds. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]
When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.
Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.
FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.
It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.
So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.
Discussion
I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.
From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.
There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.
Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.
Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?
Shouts
To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.
To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It
the post was a troll. somebody took an ancient anti-Mac rant and search/replaced "Mac" with *BSD. why fall for it and gratify the sad loser!