Re: [PATCH] mm: Implement swap prefetching tweaks

[Con Kolivas]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/