Date: Sat, 25 Jan 2003 23:08:32 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Steve Kargl <sgk@troutmask.apl.washington.edu>, Robert Watson <rwatson@FreeBSD.ORG>, Gary Jennejohn <garyj@jennejohn.org>, <arch@FreeBSD.ORG> Subject: Re: New scheduler - Interactivity fixes Message-ID: <20030125230350.O7994-100000@mail.chesapeake.net> In-Reply-To: <200301260348.h0Q3m65F024913@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
If you just want the interactivity fixes see the bottom of this email. Thanks for the help everyone! On Sat, 25 Jan 2003, Matthew Dillon wrote: > :I'd be very interested in hearing a critique of the API. There are a few > :things that I think are missing now. For example, a sched_exec(). Also, > :I think sched_fork() should be a finer grained thing like: > : > :sched_fork_kse() > :sched_fork_kseg() > :sched_fork_td() > :sched_fork_proc() > > So far the API is sufficient for the fractional-fair-share I intend > to implement later on. Groovy. I firmly believe the only way to get a good abstraction here is to see what a few consumers would look like and generalize to meet their needs. So far the abstraction seems to work well for 2 schedulers. :-) > > One thing I noticed was that the runq_*() procedures are in kern_switch.c > when, in fact, they are only used by sched_*() functions (and in the > workup I did of my own scheduler I didn't use them at all). That *might* > argue for moving them into sched_*() or into their own file. I only > hesitate because they are rather involved despite being sched_*() specific. At some point it would be nice for the per cpu runqs to be completely scheduler independant instead of existing as scheduler support code. This way we could switch schedulers on the fly and they could just take over the common run queues. Anyway, they aren't in a sched_ file because both schedulers use them. Although they could be inlined since each function is used only once in each scheduler. > > :I'm still not sure about the flip-flop that you're talking about. The > :others should be very quick to fix. I'll get a patched version going > :pretty quickly here. > : > :Thank you very much for the review matt. This is the most thorough > :feedback I've received yet. > : > :Cheers, > :Jeff > > I think I misread that part of the code. Ah, I see what happened. > I misread the sched_setup() code. I thought it was indexing into > another cpu's kseq. > > This implies that either process ping-ponging is not a problem > relative to the other issues, or that it is more subtle... perhaps > an unstable ping pong occurs in the rescheduling code (since you > reschedule every time the slice runs out). I think the issue was related to not adjusting the queue for interactive processes after they slept and woke up. Also, the missing sched_sleep() in the cv code really hosed things. The other problems you pointed out were very correct though. I have updated the file. It's available at http://www.chesapeake.net/~jroberson/sched_smp.c You'll need to update your kern_condvar.c to fix the select problem. This implements fixes for most things that we discussed other than the td_slptime adjustment. That's going to come later. With this patch I'm listening to mp3s, doing a make -j4 buildworld, running mozilla, and typing this email all at once without any latency. :-) Cheers, 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?20030125230350.O7994-100000>