On Thu, Feb 26, 2009 at 9:19 AM, Tim Kientzle <kient...@freebsd.org> wrote: > Robert Watson wrote: >> >> On Wed, 25 Feb 2009, Tim Kientzle wrote: >> >>>> I have not gone through the process scheduler code of Free BSD. Hence, I >>>> am not yet aware about the current support for Multicore Architectures. >>> >>> Since you posted to a lot of different lists, I think you probably don't >>> already use FreeBSD. (If you did, why would you post to NetBSD and >>> DragonflyBSD lists?) Scheduler work is quite complex and interacts heavily >>> with the rest of the system; it may not be a good choice for someone who >>> doesn't already have a lot of experience with FreeBSD. >> >> All the things you say are true, but let's not be too hard on the new guy, >> however -- many of our GSoC students don't have previous FreeBSD >> kernel-hacking experience. However, it does mean that they have to pick >> project ideas that are well-suited to a significant warmup and investigation >> period on the front end of the project. > > I apologize to Siddharth and others if I came off overly > harsh. My intention was to caution him that he should > plan for a lot of work prior to GSoC if he wants to > tackle something that's at the core of the OS like this. > >> I'm also not convinced that a scheduler project along these lines would be >> the most successful, but I wonder if a more experimental-spin proposal for >> looking at how to investigate poor scheduling decisions using dtrace, >> instrumentation and metrics to help us understand performance on NUMA >> systems, and exploring the impact of heuristics might go a long way. > > That's a good idea. The thing that's always impressed > me about scheduling work is how very difficult it is to > test. It's easy to change the scheduler code; it's > much harder to measure whether those changes have > made the scheduler better or not. > > Some testing support would help. Ideally, something > non-intrusive that could be easily run on a lot > of different machines so as to collect better information > about the impacts of scheduler changes: > * Load balancing: How effectively are all cores being used? > * CPU switching: What percentage of the time does a thread > stay on the same core? > * NUMA statistics: How often does a thread get scheduled on a different > processor from it's allocated memory? > * Priority inversion: How often is a higher-priority thread > idle while a lower-priority thread is running? > > A student who built such a tool and then ran some tests > with a variety of hardware and workloads could really > do a lot to advance scheduler development. Eventually, > turning such a tool into something that anyone could run > and upload data to a central collection site could be > a huge advance.
Speaking from experience, this is the way to go. If you don't do this you'll end up producing a potential black hole in terms of time and resources, which doesn't help your reputation on the project. Some food for thought. Cheers, -Garrett _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
