Found this interesting link regarding NetBSD’s kernel scheduler over at BSDForums: “This paper presents the design and implementation of a two-level thread scheduling system on NetBSD. This system provides a foundation for efficient and flexible threads on both uniprocessor and multiprocessor machines. The work is based on the scheduler activations kernel interface proposed by Anderson et al. for user-level control of parallelism in the presence of multiprogramming and multiprocessing.”
An Implementation of Scheduler Activations on NetBSD
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
how user friendly is Net/Open BSD compared to FreeBSD.. i don’t find FreeBSD particularly friendly compared to any linux distro, but i’m willing to try them out.. should i give up already or?
If you’re looking for friendly, you should probably go somewhere else (esp if you find FreeBSD unfriendly). Last time I tried NetBSD (about a year ago), it was using an old-school UNIX style inst (plain text, not even the ANSI-esque menus that FreeBSD and Slackware use).
NetBSD is great for running on oddball hardware (my Dreamcast and Sun IPC spring to mind), but I’d use FreeBSD on a PC, unless you’re looking to have every possible machine you own use the same OS.
If you want user friendliness, stay with Lycoris and maybe Mandrake if you are more than a simple newbie.
Traditionally, NetBSD (as all BSDs, originally) had
no thread concept. All major OSes now has some
thread implementation. There are two major ways
of doing this: non-preemptible user-level threads
and preemptible kernel-level threads. Linux has
the latter, Solaris the former (and recently also
the later). The NetBSD folks considered it would be
a waste of kernel memory (to expensive!) to map every
thread to a kernel-schedulable entity! So they took
a M->N mapping scheme invented 1990, that assigns
N “virtual CPUs” to be shared among M threads.
They gain full preemptiveness while keeping the
footprint small. Tricky to implement, though.
An example of how NetBSD is not the first to
invent and implement features (like, say, Linux 🙂
but waits some time and learns from others’ struggle…
OTOH, they have invented the new dynamic booting
scheme using rcorder, which now spreads over to other OSes.
So NetBSD is interesting to watch, but not for the faint
of heart.
I know that freebsd is reworking there kernel, extensively, and it will be fully threaded. So my question is how do these two OS’s compare, on this narrow issue ONLY. what is the threading model that freebsd is implementing and how is it similar to the above and how do they differ?
AFAIK, FreeBSD also tries to incorporate threads
into the kernel. The work has been a bit stalled
lately, but goes under the name KSE (if you want
to search the FreeBSD web).
The basis is the same (Sechduler Activations, SA),
however the implementation may differ.
One reason that it may differ is its close connection
to their SMP implementations.
NetBSD has no official
support for SMP yet – but there’s a branch(es?)
of -current that implements SMP for i386 (sommerfeld)
and maybe also sparc. (Possibly only as patches – don’t
know).
FreeBSD on the other hand already has an SMP implemetation,
but with much to desire. Nothing like the Linux SMP.
This has spurred the next generation SMP implementation,
SMPng, that is supposed to come in 5.0 (Nov. -02).
Sum: NetBSD: SA, no SMP, FreeBSD: SMP, no SA.
Since the FreeBSD SA-based KSE isn’t finished, it is hard
to compare its technical merits with NetBSD, but there
is an interesting NetBSD/Linux comparison in the paper. The speed is on par with Linux, beating
it in some tests, loosing in others. One particular test
Linux is significantly faster, I think it was thread
creation, 2 or 3 times faster. The NetBSD author seemed
to take that as a challenge. 🙂
NetBSD has no official support for SMP yet – but there’s a
branch(es?) of -current that implements SMP for i386
(sommerfeld) and maybe also sparc. (Possibly only as patches –
don’t know).
NetBSD has “official” support for SMP on Alpha and VAXen. Has
had for about a year (IIRC, Alpha was announced to run SMP in
multi-user in Feb. 2001). i386 is on a branch, but there is
no SMP support for sparc or, e.g., macppc (except spinup). Reading
the mailing lists, it seems some people are working on those
every now and then, though. For sparc, there was some big
show stopper, for which there’s no solution yet (at least not
one that has been discussed on [email protected]).
Of course, the NetBSD SMP implememntation is currently
“big lock”, AFAIK. Some kernel modules, though, are not
under kern big lock, but have their own already.
NGPT : Next Generation POSIX Thread
http://www.opengroup.org/rtforum/jan2002/slides/linux/abt.pdf
Interesting. I thought the N:M was mostly of
research interest, but it seems like IBM is
taking it seriously for (extremely) threaded
(server) applications. In the slide show they talk
about applications with several 10K concurrent
processes… I can see the benefit there.
Reading cvs-all on the FreeBSD mailing lists they’re working good on KSE (latest patch has been added to the official tree I think), also they’re removing a lot of GIANTS lately, so -CURRENT should speed up a lot on SMP machines now.
First let me say this is a nice paper. If the implementation captures the ideas then netBSD will have one of the best threading libraries available. This will not be terribly obvious until the SMP support catches up, but that’s a chicken and the egg problem. You have to start somewhere, and this is a nice place to start.
Next Generation POSIX Threading for Linux (see post by bact’) is a vast improvement over the current Linux implementation. However, it will not be able to reach its full potential until there is good kernel support for threads. Linus has several times stated he does not like threads, so I don’t think this will happen soon. The ability of one man to block development efforts is both a blessing and a curse for Linux. Maybe after all other OSs have a good threading implementation Linus will give in.
And in response to Thorbjörn M:N has been in practical use in AIX, Solaris, Tru64, etc for some time now. When there are 20K threads on a 8 processor machine it is almost a must.
When’s 1.6 due out?
Non-preemptable threads? What’s next, cooperative multitasking, “because it’s leaner”? Gimme a break…
Apparently, 1.6 was originally supposed to be out today,
but I remember the schedule was delayed by (at least ?)
one week. But in any case, I guess 1.6 should be out
Real Soon Now.
However, 1.6 won’t have scheduler activations; they aren’t
in -current yet, either, but on a branch.
If you have 60 000 concurrent threads in
your application Speed matters.
The user-land thread concept is actually
a form of cooperative scheduling. The user-
land threads (like the pthreads lib) are
faster in many mays, but do have significant
drawbacks… which is why they have implemented
the M:N concept. Kernel threads that are fast.
Read the article.
NetBSD takes a very conservative approach to development. It is one lean mean operating system. However, they also are willing to take risks, as in creating an entirely new rc system that does an awesome job of resolving dependencies between services as they start up. This work has now been adopted by FreeBSD and will be the default for 5.0. NetBSD tends to wait a little longer than others to implement the latest and greatest features. But when they do it, they do it right. I think somewhere on their website they describe themselves as a “stable research platform”.