From: Andrew Morton <akpm@linux-foundation.org>
To: "Steve French" <smfrench@gmail.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: pagevecs of more than PAGEVEC_SIZE pages
Date: Thu, 22 May 2008 22:54:59 -0700 [thread overview]
Message-ID: <20080522225459.5a6f7acc.akpm@linux-foundation.org> (raw)
In-Reply-To: <524f69650805221213i62488a4fk5a906b2726b9b96a@mail.gmail.com>
On Thu, 22 May 2008 14:13:07 -0500 "Steve French" <smfrench@gmail.com> wrote:
> Now that various servers support processing larger than 64K file
> writes, it would be helpful to have pagevecs that are larger than 14
> pages (PAGEVEC_SIZE).so an array of more pages could be passed to
> kernel_sendmsg (thus allowing writes larger than 56K, depending on
> wsize - the server limit is currently 8MB)
You can pass multiple pagevecs into kernel_sendmsg?
> pagevec_lookup_tag (and the inline function pagevec_space which I
> don't use) is the main place that cifs needs a pagevec instead of
> simply an array of pages and PAGEVEC_SIZE does not seem to matter
> there (it works if I malloc a structure with more pages and request
> more than 14 pages out of pagevec_lookup_tag). Is there another
> better alternative other than defining a larger pagevec (pagevec2 or
> cifs_pagevec)? Should I simply kmalloc something larger than a
> pagevec and cast a (struct pagevec *) to it?
We could make pagevecs variable-sized easily enough - add a `struct
page **' to it. But it's more overhead and this is the first time I've
seen demand for it?
next prev parent reply other threads:[~2008-05-23 5:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-22 19:13 pagevecs of more than PAGEVEC_SIZE pages Steve French
2008-05-23 5:54 ` Andrew Morton [this message]
2008-05-23 9:29 ` Evgeniy Polyakov
2008-05-23 17:13 ` Steve French
2008-05-24 10:38 ` Evgeniy Polyakov
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=20080522225459.5a6f7acc.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=smfrench@gmail.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