[<prev] [next>] [day] [month] [year] [list]
Message-ID: <614333.44648.qm@web32604.mail.mud.yahoo.com>
Date: Sun, 21 Sep 2008 05:53:32 -0700 (PDT)
From: Martin Knoblauch <knobi@...bisoft.de>
To: Peter Staubach <staubach@...hat.com>,
Chuck Lever <chucklever@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Greg Banks <gnb@...bourne.sgi.com>,
linux-nfs list <linux-nfs@...r.kernel.org>,
linux-kernel@...r.kernel.org,
Peter zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [RFC][Resend] Make NFS-Client readahead tunable
> >
> > I agree that a mount option would allow more fine-grained control over
> > readahead. A system wide parameter controlling readahead has always
> > been a weakness. Readahead, as implemented in the VFS, has a
> > *per-file descriptor* context, however, which operates automatically
> > (and can be tuned at run-time by an application with [mf]advise(2).
> >
> > As a future feature, this might work in better combination with the
> > per-mount bdi changes proposed by Peter to provide maximal flexibility
> > without exposing yet another confusing knob that could help some
> > workloads but hurt others.
>
> And perhaps add some dynamic tuning capabilities to the NFS client
> code to just make it do "the right thing". This would be better
> than any tunables and would help to serve in other situations, such
> as high bandwidth/latency networks, overloaded servers who don't
> need more read-ahead READ requests piled on, etc...
>
this goes over my capabilities, but would certainly help the situation. But then I would hate to see Sun/Linux going off the hook, because Linux just played nice :-)
Cheers
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists