![]() | |||||||||||||
Messages in this thread |
On Sunday 12 March 2006 16:27, Mike Galbraith wrote: > On Sat, 2006-03-11 at 23:54 -0500, Lee Revell wrote: > > echo 64 > /sys/block/hd*/queue/max_sectors_kb > > > > There is basically a straight linear relation between whatever you set > > this to and the maximum scheduling latency you see. It was developed to > > solve the exact problem you are describing. > > Ah, a very useful bit of information, thanks. > > It won't help Con though, because he'll be dealing with every possible > configuration. I think he's going to have to either submit, wait, > bandwidth limiting sleep, repeat or something clever that does that. > Even with bandwidth restriction though, seek still bites mightily, so I > suspect he's stuck with little trickles of IO started when we'd > otherwise be idle. We'll see I suppose. What I'm doing with that last patch works fine - don't prefetch if anything else is running. Prefetching is not a performance critical function and we cannot know what tasks are scheduling latency sensitive. With that latest patch the most expensive thing is doing nr_running(). Assuming anything is running, it only needs to do that once every 5 seconds - and only after something is in swap. Furthermore it doesn't do it if swap prefetch is disabled with the tunable. I don't think this is an expensive operation in that context and certainly avoids any problems with it. I could hack in a weighted load variant of it so that prefetch does run when only nice 19 tasks are running on top of it so that perhaps low priority compiles, distributed computing clients et al don't prevent prefetching from happening - I could do this on top of the current patch. I'd like to see that last patch go in. Does anyone have another alternative? Cheers, Con - 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: 2006-03-12 08:39 [from the cache] ©2003-2008 | |||||||||||||