From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Steve French <smfrench@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
David Howells <dhowells@redhat.com>,
sfrench@samba.org, jaharkes@cs.cmu.edu,
Andrew Morton <akpm@linux-foundation.org>,
vandrove@vc.cvut.cz
Subject: Re: Networked filesystems vs backing_dev_info
Date: Sat, 27 Oct 2007 23:30:25 +0200 [thread overview]
Message-ID: <1193520625.27652.30.camel@twins> (raw)
In-Reply-To: <524f69650710271402g65a9ec1cqcc7bc3a964097e39@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]
On Sat, 2007-10-27 at 16:02 -0500, Steve French wrote:
> On 10/27/07, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > Hi,
> >
> > I had me a little look at bdi usage in networked filesystems.
> >
> > NFS, CIFS, (smbfs), AFS, CODA and NCP
> >
> > And of those, NFS is the only one that I could find that creates
> > backing_dev_info structures. The rest seems to fall back to
> > default_backing_dev_info.
> >
> > With my recent per bdi dirty limit patches the bdi has become more
> > important than it has been in the past. While falling back to the
> > default_backing_dev_info isn't wrong per-se, it isn't right either.
> >
> > Could I implore the various maintainers to look into this issue for
> > their respective filesystem. I'll try and come up with some patches to
> > address this, but feel free to beat me to it.
>
> I would like to understand more about your patches to see what bdi
> values makes sense for CIFS and how to report possible congestion back
> to the page manager.
So, what my recent patches do is carve up the total writeback cache
size, or dirty page limit as we call it, proportionally to a BDIs
writeout speed. So a fast device gets more than a slow device, but will
not starve it.
However, for this to work, each device, or remote backing store in the
case of networked filesystems, need to have a BDI.
> I had been thinking about setting bdi->ra_pages
> so that we do more sensible readahead and writebehind - better
> matching what is possible over the network and what the server
> prefers.
Well, you'd first have to create backing_dev_info instances before
setting that value :-)
> SMB/CIFS Servers typically allow a maximum of 50 requests
> in parallel at one time from one client (although this is adjustable
> for some).
That seems like a perfect point to set congestion.
So in short, stick a struct backing_dev_info into whatever represents a
client, initialize it using bdi_init(), destroy using bdi_destroy().
Mark it congested once you have 50 (or more) outstanding requests, clear
congestion when you drop below 50.
and you should be set.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-10-27 21:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-27 9:34 Networked filesystems vs backing_dev_info Peter Zijlstra
2007-10-27 15:22 ` Jan Harkes
2007-10-27 15:32 ` Peter Zijlstra
2007-10-27 21:02 ` Steve French
2007-10-27 21:30 ` Peter Zijlstra [this message]
2007-10-27 21:37 ` Peter Zijlstra
2007-10-28 7:46 ` Petr Vandrovec
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1193520625.27652.30.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=jaharkes@cs.cmu.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sfrench@samba.org \
--cc=smfrench@gmail.com \
--cc=vandrove@vc.cvut.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.