Messages in this thread | | | Subject | Re: still nfs problems [Was: Linux 2.6.37-rc8] | From | James Bottomley <> | Date | Fri, 07 Jan 2011 13:11:07 -0600 |
| |
On Fri, 2011-01-07 at 19:02 +0000, Russell King - ARM Linux wrote: > On Fri, Jan 07, 2011 at 01:53:25PM -0500, Trond Myklebust wrote: > > I'd still like to keep the existing code for those architectures that > > don't have problems, since that allows us to send 32k READDIR requests > > instead of being limited to 4k. For large directories, that is a clear > > win. > > For the NOMMU case we will just go back to using a single page for > > storage (and 4k READDIR requests only). Should I just do the same for > > architectures like ARM and PARISC? > > I think you said that readdir reads via the vmalloc mapping of the > group of pages, but XDR writes to the individual pages.
Actually it's the other way around, but the point still stands.
> As I understand NFS, you receive a packet, you then have to use XDR > to unpack the data, which you presumably write into the set of > struct page *'s using kmap? > > Isn't a solution to have XDR write directly into the vmalloc mapping > rather than using struct page * and kmap?
So, unfortuantely, I looked at doing this and we can't. the ->readdir() call takes an array of pages, not a kernel virtual address of the pages, so there's no way to tell it to use a different mapping from the usual kernel one on them.
On the other hand, the xdr routines, since they take the pages anyway, could use a scatterlist approach to writing through the kernel mapping instead of using vmap ... we have all the machinery for this in lib/scatterlist.c ... it's not designed for this case, since it's designed to allow arbitrary linear reads and writes on a block scatterlist, but the principle is the same ... it looks like it would be rather a big patch, though ...
James
| |