From: Rob Landley <rlandley@parallels.com>
To: Daniel Stodden <daniel.stodden@citrix.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: Cache flush question.
Date: Tue, 4 Jan 2011 08:00:05 -0600 [thread overview]
Message-ID: <4D2327E5.3080106@parallels.com> (raw)
In-Reply-To: <1294130649.3529.96.camel@ramone>
On 01/04/2011 02:44 AM, Daniel Stodden wrote:
>
> Hi anyone.
>
> If somebody's got a sec to enlighten me, there's some phenomenon I
> recently came across and found somewhat counterintuitive first.
>
> Whenever I
>
> 1. Dirty a bunch of pages backed by an NFS mount on some server.
>
> 2. Block the traffic with iptables (TCP, assuming that mattered).
> Still plenty of writeback pending.
>
> 3. Sync
>
> I see #3 drive the dirty count in /proc/meminfo drop back to
> almost-zero, immediately. The sync itself blocks, though.
>
> So the pages are called clean the moment the write got queued, not
> acked? Leaving the rest just to retransmits by the socket then? Is this
> just done so because one can, or would that order rather matter for
> consistency?
At a wild guess, maybe you're experiencing what Jim Gettys dubbed
"buffer bloat".
http://lwn.net/Articles/419714/
Specficially, does ifconfig show a txqueuelen of 1000 for your device?
That means the device is buffering 1000 outbound packets, for no readily
apparent reason (other than to screw up latency). With an MTU of 1500
that's a megabyte and a half of outgoing data constipated in the network
layer.
NFS also has some cacheing of its own I don't understand yet, for
"non-idempotent" transactions. Described in this OLS paper:
http://kernel.org/doc/ols/2006/ols2006v2-pages-59-72.pdf
Rob
next prev parent reply other threads:[~2011-01-04 14:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-04 8:44 Cache flush question Daniel Stodden
2011-01-04 14:00 ` Rob Landley [this message]
2011-01-04 14:32 ` Trond Myklebust
2011-01-05 23:15 ` Daniel Stodden
2011-01-06 7:33 ` Rob Landley
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=4D2327E5.3080106@parallels.com \
--to=rlandley@parallels.com \
--cc=daniel.stodden@citrix.com \
--cc=linux-nfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).