Date: Thu, 26 Feb 2009 09:24:20 -0800 From: Garrett Cooper <yanefbsd@gmail.com> To: Tim Kientzle <kientzle@freebsd.org> Cc: Siddharth Prakash Singh <spsneo@gmail.com>, Robert Watson <rwatson@freebsd.org>, freebsd-hackers@freebsd.org Subject: Re: Google SoC 2009 Idea Message-ID: <7d6fde3d0902260924r45ebb7c8i46cd6daf43a8171d@mail.gmail.com> In-Reply-To: <49A6CF27.3000203@freebsd.org> References: <e8e9f3930902240943o2e2f4b1bh34916b775692a26f@mail.gmail.com> <49A5D6FC.1090800@freebsd.org> <alpine.BSF.2.00.0902261620100.41191@fledge.watson.org> <49A6CF27.3000203@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 26, 2009 at 9:19 AM, Tim Kientzle <kientzle@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?) =A0Scheduler work is quite complex and interacts h= eavily >>> with the rest of the system; it may not be a good choice for someone wh= o >>> 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 gu= y, >> however -- many of our GSoC students don't have previous FreeBSD >> kernel-hacking experience. =A0However, it does mean that they have to pi= ck >> project ideas that are well-suited to a significant warmup and investiga= tion >> period on the front end of the project. > > I apologize to Siddharth and others if I came off overly > harsh. =A0My 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 f= or >> 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. =A0The thing that's always impressed > me about scheduling work is how very difficult it is to > test. =A0It'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. =A0Ideally, 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: > =A0* Load balancing: =A0How effectively are all cores being used? > =A0* CPU switching: =A0What percentage of the time does a thread > stay on the same core? > =A0* NUMA statistics: =A0How often does a thread get scheduled on a diffe= rent > processor from it's allocated memory? > =A0* Priority inversion: =A0How 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. =A0Eventually, > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7d6fde3d0902260924r45ebb7c8i46cd6daf43a8171d>