![]() | ||||||||||
Messages in this thread |
Daniel Phillips wrote: > > On January 8, 2002 11:21 pm, Andrew Morton wrote:> > Daniel Phillips wrote:> > > The preemptible kernel can reschedule, on average, sooner than the > > > scheduling-point kernel, which has to wait for a scheduling point to roll > > > around.> >> > Yes. It can also fix problematic areas which my testing > > didn't cover.> > I bet, with a minor hack, it can help you *find* those problem areas too. > You compile the two patches together and automatically log any event along > with the execution address, where your explicit schedule points failed to > reschedule in time. Sort of like a profile but suited exactly to your > problem. Well, one of the instrumentation patches which I use detects a scheduling overrun at interrupt time and emits an all-CPU backtrace. You just feed the trace into ksymoops or gdb then go stare at the offending code. That's the easy part - the hard part is getting sufficient coverage. There are surprising places. close_files(), exit_notify(), ... > This just detects the problem areas in normal kernel execution, not > spinlocks, but that is probably where most of the maintainance will be anyway. > > By the way, did you check for latency in directory operations? Yes. They can be very bad for really large directories. Scheduling on the found-in-cache case in bread() kills that one easily for most local filesystems. There may still be a problem in ext2. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2005-03-22 12:15 [from the cache] ©2003-2008 | ||||||||||