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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
