login
Search
Since the decision to demote ULE [story] 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:
"ULE works again with preemption and kse and so on. As far as I know, the only two problems with ULE currently are these:[...]"
Note that Jeff follows up his initial post with a correction (there are three current problems), and later, that he's fixed the second listed issue. Also discussed are plans to MFC this work to the RELENG_5 stable branch and future direction of ULE and 4BSD scheduler development.
From: Jeff Robberson [email blocked] To: freebsd-current Subject: cvs commit: src/sys/kern sched_ule.c (fwd) Date: 2004-12-13 13:12:25 ULE works again with preemption and kse and so on. As far as I know, the only two problems with ULE currently are these: 1) nice +20 processes steal too much time from workloads that have some amount of idle time and lots of context switches (buildworld). 2) a nice +20 process can not be killed until there is some idle time in the system. 3) Performance is not what it could be, especially on HTT. If you encounter any other problems with ULE, please email me directly, without a current cc, as this will ensure the least amount of lag in reply. Thanks, Jeff ---------- Forwarded message ---------- Date: Mon, 13 Dec 2004 13:09:33 +0000 (UTC) From: Jeff Roberson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/kern sched_ule.c jeff 2004-12-13 13:09:33 UTC FreeBSD src repository Modified files: sys/kern sched_ule.c Log: - Take up a 'slot' while we're on the assigned queue, waiting to be posted to another processor. Otherwise, kern_switch() gets confused and tries to sched_add(NULL). Revision Changes Path 1.138 +16 -16 src/sys/kern/sched_ule.c
From: Ivan Voras [email blocked] Subject: Re: cvs commit: src/sys/kern sched_ule.c (fwd) Date: 2004-12-13 16:50:04 Jeff Roberson wrote: > ULE works again with preemption and kse and so on. As far as I know, the > only three problems with ULE currently are these: Nice! Will it get to RELENG_5 soon? I'd like to try it but don't want to switch to -current for it :)
From: Jeff Roberson [email blocked] Subect: Re: cvs commit: src/sys/kern sched_ule.c (fwd) Date: 2004-12-13 17:00:25 On Mon, 13 Dec 2004, Ivan Voras wrote: > Jeff Roberson wrote: > > ULE works again with preemption and kse and so on. As far as I know, the > > only three problems with ULE currently are these: > > Nice! Will it get to RELENG_5 soon? I'd like to try it but don't want to > switch to -current for it :) I imagine that since it's totally broken on 5.3 re wont mind if I merge the changes right away. I'll find out soon.
From: Scott Long [email blocked] Subject: Re: cvs commit: src/sys/kern sched_ule.c (fwd) Date: 2004-12-13 17:26:10 Ivan Voras wrote: > Jeff Roberson wrote: > >> ULE works again with preemption and kse and so on. As far as I know, the >> only three problems with ULE currently are these: > > > Nice! Will it get to RELENG_5 soon? I'd like to try it but don't want to > switch to -current for it :) > RELENG_5 is the stable branch. If quality testing goes into ULE in HEAD and it's shown to be as stable as 4BSD then we can consider it for RELENG_5 in the future. Given the incredible problems that we had in the scheduler leading up to 5.3, I'm not excited about quickly merging these things. Scott
cool -- hope to see it soon i
cool -- hope to see it soon in RELENG_5
RELENG-5
I want to see it in 5-STABLE as well. I don't really see Scott Long's point. If ULE is totally broken in 5-RELEASE, merging the patches back to 5-STABLE would not make the situation worse, no? Especially since it is disabled by default.
On the other hand, those who track -STABLE on a desktop computer (not in a production environment) and are willing to mess with commenting out sections in the source code to reenable ULE already, will benefit greatly from these bugfixes. Many people do that, which suggests there is a demand for it.
I dont consider the chemistry
I dont consider the chemistry between hackers ideal as far as ULE
is concerned.
They seem to the outside user's land as if there is a negative atmospehere.
3 months went on and there were comments even on the orpahncy
of the ULE project. Suddenly roberson shows up again with
a "on the foot" written note, and on the other side the rest of the hackers
dont seem too excited about that, giving the world the impression...
nobody cares...
Well, SCHED_4BSD is fine for me and i believe many others,
but why on earth so much hype on ULE at its early intoduction
if nobody seems to give a damn 3 long months after it was marked broken??
Because
Well, SCHED_4BSD is fine for me and i believe many others,
but why on earth so much hype on ULE at its early intoduction
if nobody seems to give a damn 3 long months after it was marked broken??
Because it was given a cool sounding name, and a paper saying how much better it was than what Linux had.
Better?
Sounds funny since ULE is a port of Ingo's O(1) scheduler.
And
Matt Dillon said he can write a better scheduler than ULE
haha Dfly will certainly clobber Fbsd
Saying you can write somethin
Saying you can write something better and actually writing something better are two totally different things. I'd reserve judgement until Matt Dillon actually *writes* (and implements in DFly) a better scheduler :)
Common sense
tells me that Matt Dillon already has proven his abilities, showcasing his coding prowess in past stints with FreeBSD and Linux.
If you watch Dfly progress especially with VFS changes you can really see the effort and efficiency put into producing what will be the next big BSD.
Dfly will focus on performance so a high quality-speed scheduler is a requirement. Obviously it will take time but eventually the Dfly team can write one.
This is an over simplificatio
This is an over simplification. I used only the double queueing mechanism, and none of the priority calculations, slice calculations, interactivity mechanisms, or load balancing.
The only thing that I claimed was better in my paper was the interactivity, which was demonstratably better at the time. I don't know how it is now, because I haven't really looked at it.
If it is fine, you don't have
If it is fine, you don't have to switch. In many cases it is better, and in some it still needs work. In the future, it will be even more imoprtant that we have a shceduler with independent run queues. So perhaps for your applications it is not important, but understand for others it is very important.
Anyway, I was very busy for some time, and the decision was made not to use it in 5.3-RELEASE so I did not over stress myself with fixing bugs other people introduced. I apologize, but life happens.