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/