On 7 Dec 2016, at 18:10, Benjamin Coddington wrote:
On 7 Dec 2016, at 17:59, Trond Myklebust wrote:
On Dec 7, 2016, at 17:55, Benjamin Coddington <bcodding@xxxxxxxxxx>
wrote:
On 7 Dec 2016, at 17:41, Trond Myklebust wrote:
On Dec 7, 2016, at 17:34, Benjamin Coddington
<bcodding@xxxxxxxxxx> wrote:
static
@@ -921,7 +930,7 @@ static int nfs_readdir(struct file *file,
struct dir_context *ctx)
desc->ctx = ctx;
desc->dir_cookie = &dir_ctx->dir_cookie;
desc->decode = NFS_PROTO(inode)->decode_dirent;
- desc->plus = nfs_use_readdirplus(inode, ctx) ? 1 : 0;
+ desc->plus = nfs_use_readdirplus(inode, ctx, dir_ctx) ? 1 : 0;
This fixes desc->plus at the beginning of the readdir() call.
Perhaps we
should instead check the value of ctx->use_readdir_plus in the call
to
nfs_readdir_xdr_filler(), and just resetting cts->use_readdir_plus
at the
very end of nfs_readdir()?
I don't understand the functional difference. Is this just a
preference?
No. The functional difference is that we take into account the fact
that a
process may be in the readdir() code while a GETATTR or LOOKUP from a
second process is triggering “use readdirplus” feedback.
This should only matter if the concurrent processes have different
buffer
sizes or start at a different offsets -- which shouldn't happen with
plain
old 'ls -l'.
.. or maybe I'm wrong if, hmm.. if acdirmin ran out (maybe?).. or if
we mix
'ls -l' and 'ls'.. or if we have pages getting reclaimed.. OK. I'll
try it.
This doesn't help.
The issue is that anything more than a couple of processes cause
contention
on the directory's i_lock. The i_lock is taken x entries x processes.
The
inode flags and serialization worked far better.
If we add another inode flag, then we can add a DOING_RDPLUS. A process
entering nfs_readdir() that sees ADVISE and not DOING clears it and sets
DOING and remembers to clear DOING on exit of nfs_readdir(). Any
process
that sees DOING uses plus.
Ben
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
