public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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?


  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