From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Xeno <xeno@overture.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: 2.4: NFS client kmapping across I/O
Date: 29 Jan 2002 10:05:31 +0100 [thread overview]
Message-ID: <shshep5wmqs.fsf@charged.uio.no> (raw)
In-Reply-To: <3C560804.C68BC6F4@overture.com>
In-Reply-To: <3C560804.C68BC6F4@overture.com>
>>>>> " " == xeno <xeno@overture.com> writes:
> Trond, thanks for the excellent fattr race fix. I'm sorry I
> haven't been able to give feedback until now, things got busy
> for a while. I have not yet had a chance to run your fixes,
> but after studying them I believe that they will resolve the
> race nicely, especially with the use of nfs_inode_lock in the
> recent NFS_ALL experimental patches. FWIW.
Note: the nfs_inode_lock is not in itself part of any 'fix'. It is
merely a substitute for the current BKL protection of attribute
updates on NFS. The BKL gets dropped from NFS + rpciod in the patch
linux-2.4.x-rpc_bkl.dif which is, of course, included in NFS_ALL.
> I've also thought about pushing the kmaps and kunmaps down into
> the RPC layer, so the pages are only mapped while data is
> copied to or from them, not while waiting for the network.
> That would be more work, but it looks doable, so I wanted to
> run the problem and the approach by you knowledgeable folks
> while I'm waiting for hardware to free up for kernel hacking.
This is the long term solution. We will in any case want to make the
RPC layer 'page aware' in order to be able to make use of the
zero-copy socket stuff (a.k.a. sendpage()).
I'm still not ready to detail exactly how it should be done
though. I'll have to get back to you on this one...
Cheers,
Trond
next prev parent reply other threads:[~2002-01-29 9:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-29 2:25 2.4: NFS client kmapping across I/O Xeno
2002-01-29 9:05 ` Trond Myklebust [this message]
2002-01-29 17:42 ` Hugh Dickins
2002-01-29 18:34 ` Rik van Riel
2002-01-30 0:56 ` Xeno
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=shshep5wmqs.fsf@charged.uio.no \
--to=trond.myklebust@fys.uio.no \
--cc=linux-kernel@vger.kernel.org \
--cc=xeno@overture.com \
/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