Since the decision to demote ULE in favor of the 4BSD scheduler as the default for FreeBSD’s 5.3-Release, many improvements to both schedulers have been committed. At the time it was marked broken, ULE was especially needy in light of the status of its maintainership, performance issues, and its unreliable nature in conjunction with threading and kernel preemption. Having resolved these problems, Jeff Roberson announces to -current that the ULE code is now in working order, kerneltrap reports.
ULE was supposed to be the best feature in freebsd 5.3. unfortunately its still buggy and doesnt give better performance for typical workloads. I dont care about benchmarks
It’s certainly late. As for bugs and performance, it’s not finished. When it’s in -STABLE, we’ll be able to gauge those factors.
Since Jeff Roberson has picked up maintainership, they seem to be on track for improving it. It’s stable much later than everyone expected and doesn’t yet perform as best as dev would like, but you have to remember that it hasn’t been optimized yet. There’s also a lot of cleanup they have to do to separate the scheduler infrastructure, since development has, in part, been impeded by the fact that ULE and 4BSD share some of the same source files. I dunno, I think there’s good evidence to be optimistic.
“ULE was supposed to be the best feature in freebsd 5.3. unfortunately its still buggy and doesnt give better performance for typical workloads.”
Sorry, but if you think a scheduler is the “best feature” in a release, you are confusing your operating system for a scheduler. We have had the previous scheduler for a long time, and it is good enough for most cases. ULE is nice, but not required.
I look at 5.3, and it seems to be the best FreeBSD release ever. The 5 branch is finally stable enough to put in production and has so many useful tools that make it way better than 4.x. We can finally start using these features in production. Scalability is still an issue, but the FreeBSD team is working on it and they are getting lots of work done. In the meanwhile, we have a really great system that is getting better and better.
So look at the 99% of the cup that is full rather than the 1% that is empty. ULE after all is just a scheduler.
”
Sorry, but if you think a scheduler is the “best feature” in a release, you are confusing your operating system for a scheduler”
thats a bad assumption…
“Scalability is still an issue, but the FreeBSD team is working on it and they are getting lots of work done. In the meanwhile, we have a really great system that is getting better and better.”
a major part of this scalibility work in the scheduler
“ULE after all is just a scheduler.”
I guess you dont realise the importance of a scheduler in an operating system. we can go ahead and say “freebsd after is just another operating system”. that doesnt change the fact the scalibility is very much important and that a scheduler is a major part of scalability…
I know of many reports about instability, especially on SMP in conjunction with PREEMPTION, but on my desktop puter I’ve been using it since 5.1 (till they disabled it) and I never had any problems.
Anonymous @61.95.184.— doesn’t know what he is talking about. What is a typical worlkload? There is no such thing as a ‘typical’ workload … you have to define a context (webserver? home desktop?). Anyways, on the desktop, ULE was just awesome. Playing movies (even xvid) smoothly on my athlon xp even with some c++ compile in the background. Sometimes I had to check if portbuild was still running, because desktop interactivity was _that_ good even under heavy loads.
I trial boot (winxp, freebsd, slack), and freebsd with ULE was my fastest desktop system. Slack is somewhat better than FreeBSD with SCHED_4BSD (kde on both, kernel 2.6.7 on slack) but I can hardly tell, difference is not that noticeable. The difference b/w slack and FreeBSD+ULE was very obvious on the other hand. (Furthermore, slack was one of the fastest linux distro I tried, icluding gentoo) So I’m very happy about this news. And if the performance I saw was not even optimized yet, as someone has suggested, than kudos to Jeff and all who worked on ULE.
Hopefully, they will merge it back to 5-stable (why not, as Jeff suggests, if ULE is already broken in 5.3-RELEASE, and forcibly disabled, it won’t hurt importing these new patches) soon.
doesn’t know what he is talking about.
—
ya right. personal attacks from bsd zealots. i am not suprised.
“There is no such thing as a ‘typical’ workload”
oh yes. there is. its called the target or utilisation criteria. look that up in professional benchmarking concepts
“oh yes. there is. its called the target or utilisation criteria. look that up in professional benchmarking concepts”
I would hope that 90% of us who are computer geeks don’t have to read things like professional benchmarking concepts to quantify typical workload. Typical workload is to me much like the previous post said(web server,desktop, etc) maybe throw some more detail into those high level areas and that works for me as I don’t work in a performance lab.
Also what the hell is professional benchmarking concepts. I have never heard of it. Must be for the real geeks.
I would hope that 90% of us who are computer geeks don’t have to read things like professional benchmarking concepts to quantify typical workload
—-
sure. dont read it but dont try personal attacks either
“ya right. personal attacks from bsd zealots. i am not suprised.”
bsd zealot. right. On the other hand, your first prost sounded like an ‘ULE is back … well, who cares, so what’ kinda offhand remark. Not very informative (or informed) remark in my opinion. Also “personal attacks from bsd zealots. i am not surprised” suggests that it is you who overgeneralize – in good zealot fashion. Why are you not surprised? Is it so common among BSD users to post crap in linux related threads? I don’t think so. If you check ./ or even some of the ~BSD related news on this site, you’ll see that the opposite is true: there is a massive campaign against ~BSD, its users, even its developers sometimes. Part of that campaign is anonymous posts suggesting that BSD users are zealots, just as your reply does.
Now this may bother some folks here, but let me say this: there is less zealotry among BSD users than in some other camps. But instead of throwing ‘typical bsd zealotry’ kinda remarks right and left, I can proove my point: if anyone wants to see how the average bsd user, or the bsd community thinks about linux, check out our main forum: bsdforums.org. You’ll see that there is a linux section there, and you’ll see that threads praising linux (one distro or another) are in an overwhelming majority compared to those that criticize it. Personal OS choice is not a reliegion you know.
Also: I don’t care about your choice of OS (if that’s what is bothering you: I like BSD much better than any other OS). But I am bored enough and have enough time on my hands to point out that your post was void of any meaningful content. If that makes me a zealot, well, who cares
Back on topic: I don’t have proof for my claims. It is my subjective experience with ULE. But the fact that so many developers (especially those who are desktop oriented folks) still use ULE in current despite the bugs (which hopefully are mostly corrected by now) tells at least something about its performance.
bsd zealot. right. On the other hand, your first prost sounded like an ‘ULE is back … well, who cares, so what’ kinda offhand remark. Not very informative (or informed) remark in my opinion.
—-
that was a discussion about ULE. it was no way personal.
are you justifying personal attacks in the name of promoting bsd?
“But I am bored enough and have enough time on my hands to point out that your post was void of any meaningful content. If that makes me a zealot, well, who cares
”
you didnt understand the meaning which is ignorant. typical workloads are always determined by target market. either you take time to learn or dont rant unnecessarily and yes this is not the first time I am hearing such personal attacks from the bsd zealots
I have a colo server running 5.3 and have been having quite a few issues with it under extreme MySQL loads, namely system crashes and loss of system responsiveness.
I’ve been checking out RELENG_5 fairly frequently, and even with the most recent changes + the 4BSD scheduler I’ve still experienced bizzare problems… the system still responds to pings and doesn’t reboot but for the duration of the extreme database load all ssh sessions hang and all services (while still accepting TCP connections) don’t respond.
However, with the latest RELENG_5 + ULE, the system remains snappy and responsive even under extreme database load. I’m very glad to hear ULE is fixed and stable, and will likely be checking out sched_ule.c from -CURRENT and trying it out. I’m still running into occasional strange and inexplicable problems and hopefully the latest revisions to the ULE scheduler will remedy those.
you didnt understand the meaning which is ignorant. typical workloads are always determined by target market.
You sound like the hawskinsos guy. It was you who mentioned benchmarks, without any specific reference. Typical worlkloads determenid by target market … which is? That doesn’t make too much sense either. FreeBSD’s doesn’t target desktop users, and you can generally say that it targets the ‘server market’. But you can’t speak of ‘typical worloads on the server market’ in any meaningful way without specifying what type of servers you have in mind.
FreeBSD might have problems with MySQL currently, although it shows some 30% improvement compared with 4.x in some cases. In other cases, it seems (I’m referring to Bascule’s post), it has problems … problems that ULE might help (which runs contrary to your initial post). But server running a database has different workload characteristics than a server running dns, smb, apache, etc.
Perhaps this helps _you_ understand my point better:
“Improvements in symmetric multiprocessing (SMP) virtual memory, asynchronous I/O, a native POSIX thread library, as well as other features and support from multiple vendors [in Linux] made FreeBSD a less likely choice for enterprise workloads.”
FreeBSD does, however, remain a factor in the infrastructure of the Internet itself, at least according to the founder of the ISC, the group that produces BIND, the dominant DNS (define) tool of the Internet.
“On the one hand we applaud Linux for coming out of nowhere so late in the game and creating a robust industry based on open source concepts,” said Paul Vixie, board chairman for ISC. “Furthermore, ISC hosts the main Linux kernel distribution server [kernel.org] as our way of helping the Linux community continue to thrive,” he said.
“On the other hand we use FreeBSD exclusively for f-root (in 21 cities now, usually with three servers per city) and all of our other servers and internal development,” Vixie explained. “We like the age of the platform. BSD has existed since the late 1970’s and modern FreeBSD is extremely refined and mature.”
http://www.internetnews.com/dev-news/article.php/3367381
So yes, there are areas where FreeBSD can improve, especially in SMP, virtual memory, I/O, etc – all currently under heavy development if you read -CURRENT mailing list, and there are areas where FreeBSD is ahead (security, tcp/ip perfomance, stability). But referencing ‘professional benchmarking concepts’ doesn’t help differentiate between various enterprise settings. And I still maintain that your post is neither meaningful, nor informative: “unfortunately its still buggy and doesnt give better performance for typical workloads.” The announcment is about fixing those bugs, so what’s your point? Any way you can prove your other claim that it doesn’t perform better? This sounds more like trolling, even if vaguely on topica. Furthermore, it is extremely redundant if you think of it: “ULE is still buggy” as first post in a thread which is exactly about fixing the major issues with ULE.
ps. just so you know: Fancy as it may sound, I wasn’t exactly floored by your ‘typical worload = its called the target or utilisation criteria.’ Sounds silly. (more precisely: a bit tautological). Where did you dig that up?
. It was you who mentioned benchmarks, without any specific reference. Typical worlkloads determenid by target market … which is?
—–
you do agree that freebsd has scalability issues supposed to be improved by ULE which was to be integrated with freebsd 5.3 and is not ready yet?. that should be enough. dont worry about target market.
Sounds silly. (more precisely: a bit tautological). Where did you dig that up?
—–
perhaps google will help you.
you do agree that freebsd has scalability issues [with 4BSD]
Yes, fully, as I said in my earlier post I have experienced these firsthand.
supposed to be improved by ULE
They aren’t “supposed to be improved”, they are completely and thoroughly resolved by ULE.
which was to be integrated with freebsd 5.3 and is not ready yet?.
ULE is completely functional now and has excellent performance except for the two cases which Jeff Roberson documented in his post.
I’ve sent a message to the freebsd-current mailing list describing my stability issues with 4BSD and asking Scott Long to merge the new ULE code into RELENG_5. However, I’ve already merged the changes myself (which was fairly trivial) and have been running an otherwise 5-STABLE kernel with the ULE scheduler from -CURRENT with no performance or stability issues yet. I hope my post convinces Scott Long to merge these changes, at which point ULE will be fully usable on any 5-STABLE system.
So. basically you agree with me. nice
So. basically you agree with me. nice
Yes, but I think you have an overly pessamistic view. According to the latest posts on the freebsd-current mailing list the new ULE code will hopefully be merged into RELENG_5 within the next few days, at which point this whole discussion will be moot.
“I guess you dont realise the importance of a scheduler in an operating system. we can go ahead and say “freebsd after is just another operating system”. that doesnt change the fact the scalibility is very much important and that a scheduler is a major part of scalability… ”
Actually I do understand how important the scheduler is for scalability. However, I also understand how important removing Giant Lock is too. Scalability is a work in progress. It’s getting there, but it’s still far away. While it is nice to have, the removal of giant lock from so many places and all the features they’ve added to 5.3 far outweight the inclusion of ULE. I’m not saying ULE is not important, just saying that look at the big picture. FreeBSD is getting there and in the meanwhile, it does what it’s good at really well and it is good at lots of things..
I had ULE panics left and right on various 5.2.1 and 5.3 RCs. Everytime I compile with ULE, my system goes down within an hour of the next boot. 4BSD has been rock-solid. I’ve reported on the issue each time, and the best solution has been to go 4BSD. This is on a rather old machine (400 Mhz Celeron from Gateway).
Just my experience. I’m happy that ULE is stablizing, as I have used it before with no problems (5.1 was ULE I believe) and it seemed a little faster on compiles. I can’t wait for this to make it to a -RELEASE.
Yes, but I think you have an overly pessamistic vie
—-
not at all.
According to the latest posts on the freebsd-current mailing list the new ULE code will hopefully be merged into RELENG_5 within the next few days, at which point this whole discussion will be moot.
—-
that would be good
“I’m not saying ULE is not important, just saying that look at the big picture. FreeBSD is getting there and in the meanwhile, it does what it’s good at really well and it is good at lots of things..”
i dont disagree. However ULE has still been flaky to me and talks of merging it on HEAD seems premature to me. I am entitled to my opinion on experiences without being labelled this and this right?
i dont disagree. However ULE has still been flaky to me and talks of merging it on HEAD seems premature to me. I am entitled to my opinion on experiences without being labelled this and this right?
HEAD is -CURRENT. I’m talking about merging it into RELENG_5 (5-STABLE). The only way this affects the stability of the RELENG_5 branch is that kern_switch.c and kern_sig.c need to be merged in from -CURRENT as well. Merging sched_ule.c itself cannot impact the stability of RELENG_5 because 4BSD would still be the default scheduler and therefore sched_ule.c wouldn’t even be used, however merging the new kern_switch.c and kern_sig.c might negatively impact the stability of the RELENG_5 branch. All merging ULE would do is allow those of us having trouble with 4BSD the option of using a working ULE scheduler without having to hack the new ULE code into the kernel ourselves.
what are the main differences between these schedulars? is one a time-sliced and the other prioritised with queue-jumping? is one hierarchical?
I don’t know the specific details of the implementations, but ULE is constant time and geared towards SMP workloads. 4BSD is O(n) for n processes. For the majority of workloads 4BSD is just fine, and my case is an exception because I’m putting a considerable amount of database, process, and network load on an SMP system, in which case the 4BSD scheduler has proven itself simply insufficient.
I read Roberson’s paper and studied the code a bit, and he has some nice ideas. Matt said he can do better, and I wonder what he’ll come up with for DragonFlyBSD. If it turns out to be better perhaps it will be integrated in FreeBSD, specially if PHK doesn’t try to push his agenda there.
According to the -current mailing list, Jeff is merging the changes to sched_ule.c into RELENG_5. Scott has given him approval. However, until the changes to kern_sig.c from HEAD are merged into RELENG_5, ULE will still be unstable in RELENG_5.
I read Roberson’s paper and studied the code a bit, and he has some nice ideas. Matt said he can do better, and I wonder what he’ll come up with for DragonFlyBSD. If it turns out to be better perhaps it will be integrated in FreeBSD, specially if PHK doesn’t try to push his agenda there.
As far as I know the DragonFly LWKT scheduler is constant time. However the userland scheduler still needs work. There was a story about it recently:
http://osnews.com/story.php?news_id=9142