Date: Thu, 10 Oct 2002 00:11:11 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Luigi Rizzo <rizzo@icir.org> Cc: arch@FreeBSD.ORG Subject: Re: Scheduler patch, ready for commit. Message-ID: <20021009234324.F23516-100000@mail.chesapeake.net> In-Reply-To: <20021009193501.A55534@carp.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 9 Oct 2002, Luigi Rizzo wrote: > > well, you said you posted it just to get feedback, and now in 24 hours > you declare it "ready for commit". A bit rushing, aren't you! Perhaps I wasn't clear. I was looking for an indication of whether or not this was something people were interested in having in for 5.0. I'm not going to rush the commit but by declaring it to be of a sufficient quality for commiting I was hoping to scare more poeple into reviewing it. ;-) > So to come to the specific points: > > * there is one important API function which in my opinion is > missing: -stable has a function, curpriority_cmp, which compares > the priority of a currently running "thing" (process/thread) > with that of a newly awaken one, and decises who has more right > to get the CPU. This decicion is currently only made within code that has intimate knowledge of the scheduler. ie, within sched_4bsd.c. There is currently no need for an externally visible api. sched_wakeup() handles this specific case. The only other places that knows a significant amount about priorities is kern_mutex.c. It calls a hepler function to adjust priorities though. > > * Another API which should be made generic is forward_roundrobin(). > I believe the purpose of a "generic" version of this function > is to dispatch a generic timeout to the appropriate CPU(s). In > the FreeBSD's scheduler this timeout happens to be the roundrobin > timeout, hence the name, but other schedulers (e.g. the one we > wrote) have different timeout routines, and the dispatching > requirements vary (e.g. could need to go to a single CPU as > opposed to all cpus). FreeBSD already has generic timeout handling code. Schedulers are free to use it however they like. This timeout is only enabled in sched_4bsd.c right now. It is only using the helper function from subr_smp.c. I think good arguments could be made for puting this function in either file so I'm leaving it where it is. I only assume that schedulers will implement a handler for hardclock. So that's all I have hooks for. > > On the same grounds, sched_rr_interval() is not generic, > but specific for the freebsd scheduler. Not all schedulers > have the concept of a roundrobin interval. I agree. There is one bit of code that depends on this that I'm not intimately familiar with. My intention here was for the individual schedulers to provide a good approximation of this if they didn't support it exactly. That seems necessary for this code to work at all. (specificaly, sys/posix4/ksched.c) > > * The other thing that i would really like to see is to > call the scheduler functions through function pointers, so > life is a lot easier when we will decide to enable kldloading of > schedulers (or having multiple alternative ones). > The way to implement it is trivial, see how we did in > http://info.iet.unipi.it/~luigi/ps_sched.20020719a.diff. This is not a priority for me at the moment. I don't think it's important for now. At least not for my purposes. I'm not prepaired to deal with the overhead or the complications that arise from runtime scheduler selection. I'd just like to have an alternate scheduler ready for 5.0. This seems to be the cleanest path to that goal. I consider this an intermediate stage on the way towards a pluggable scheduler interface. > > Oh, another thing: struct proc (or struct thread, whatever it is > in -current)) contains some scheduler-specific information, such > as the priority fields. Other schedulers might need different data > structures to work on. Given that this structure is something we > should not change lightly or frequently, it would be a good idea > to provide one (1) field (e.g. a void *) to be used by the scheduler > to reach a "scheduler extension" block from it. The way we provided > this extensibility in our scheduler framework (in -stable) was to > use some padding bytes in struct proc to store an integer which is > an index in an array of extended process descriptors, but that was > just a hack motivated by the need of not changing "struct proc". > Yes, this whole problem is quite ugly. Perhaps I should be clear about my intentions. I'm not attempting to create the perfect scheduler abstraction. I'm trying to get us close enough so that I can continue my own work on a new scheduler. I believe that what I have done so far can provide a good foundation for abstrated, loadable, dynamic scheduling in the future. My real goal, however, is just to have a better scheduler for 5.0. For me that is more important than a loadable scheduler infrastructure. > Finally, thanks for working on this stuff! > Thank you very much for the feedback! Perhaps at the next BSDcon we can sit down and devise a good plan for a full featured framework. Thanks, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021009234324.F23516-100000>