Messages in this thread | | | Date | Wed, 09 Jan 2002 01:26:09 -0800 | From | Andrew Morton <> | Subject | Re: [2.4.17/18pre] VM and swap - it's really unusable |
| |
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/
| |