From: Dean Hildebrand <seattleplus@gmail.com>
To: Olga Kornievskaia <aglo@citi.umich.edu>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>,
Chuck Lever <chuck.lever@oracle.com>,
linux-nfs@vger.kernel.org
Subject: Re: size of nfsv4 writes
Date: Thu, 05 Jun 2008 17:25:18 -0700 [thread overview]
Message-ID: <484883EE.2060802@gmail.com> (raw)
In-Reply-To: <48471180.8090208@citi.umich.edu>
Olga Kornievskaia wrote:
>
>
> Trond Myklebust wrote:
>> On Wed, 2008-06-04 at 12:40 -0400, Olga Kornievskaia wrote:
>>
>>> While testing NFSv4 performance over the 10GE network, we are seeing
>>> the following behavior and would like to know if it is normal or a
>>> bug in the client code.
>>>
>>> The server offers the max_write of 1M. The client mounts the server
>>> with the "wsize" option of 1M. Yet during the write we are seeing
>>> that the write size is at most 49K. Why does client never come close
>>> to 1M limit?
Does /proc/mounts indicate 1M? As a total guess, could there be
something going on in nfs_can_coalesce_requests
</lxr-pnfs/ident?i=nfs_can_coalesce_requests>? (I can't imagine why,
but we had a pnfs problem where our additions to
nfs_can_coalesce_requests were causing similar behavior)
>>>
>>
>> I have a feeling that is due to some crap in the VM. I'm currently
>> investigating a situation where it appears we're sending 1 COMMIT for
>> every 1-5 32k WRITEs. This is not a policy that stems from the NFS
>> client, so it would appear that the VM is being silly about things.
>>
>> I'm specially suspicious of the code in get_dirty_limits() that is
>> setting a limit to the number of dirty pages based on the number of
>> pages a given BDI has written out in the recent past. As far as I can
>> see, the intention is to penalise devices that are slow writers, but in
>> practice it doesn't do that: it penalises the devices that have the
>> least activity.
>>
>>
> I think we are seeing larger than usual number of COMMIT messages.
With older kernels, no matter how I configured linux to flush dirty
pages, it would always flush too often and hence send way too many
commit messages. But more like every couple hundred megabytes.....
If you don't need the page cache, I have found that O_DIRECT can
increase performance by giving predefined points at which the client
will commit.
Dean
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-06-06 0:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-04 16:40 size of nfsv4 writes Olga Kornievskaia
2008-06-04 16:46 ` Trond Myklebust
2008-06-04 22:04 ` Olga Kornievskaia
2008-06-06 0:25 ` Dean Hildebrand [this message]
2008-06-12 21:41 ` Olga Kornievskaia
2008-06-13 16:33 ` Chuck Lever
2008-06-13 18:19 ` Olga Kornievskaia
2008-06-13 19:03 ` Chuck Lever
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=484883EE.2060802@gmail.com \
--to=seattleplus@gmail.com \
--cc=Trond.Myklebust@netapp.com \
--cc=aglo@citi.umich.edu \
--cc=chuck.lever@oracle.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 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.