public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ian Molton <ian.molton@collabora.co.uk>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Buffer allocation question
Date: Mon, 13 Sep 2010 16:51:52 +0100	[thread overview]
Message-ID: <4C8E4898.7090407@collabora.co.uk> (raw)

Hi,

I need to allocate some fairly large buffers which will be transferred 
via virtio to a hypervisor.

the pages dont have to be contiguous physically and aside from the first 
page int he transfer, the kernel wont really care about the contents of 
the buffer.

the pages do need to be mapped into userspace contiguously, however. 
They are also often dynamically resized.

the buffers can be quite large, and there can be several in flight at a 
given time. They must always be present in physical space (or virtio 
gets upset)

Obviously kmalloc() is out of the question, and given the size / 
quantity of the buffers, vmalloc() space is getting tight.

I'm struggling to find a good example of how this should be done.

the buffers will usually be filled all in one go, so it seems silly to 
fault them in a page at a time.

my first thought (before realising how limited vmalloc space is) was to 
vmalloc() them in my mmap() function, but this approach ran into trouble 
when I discovered that the mmap() call does not get called if the vma 
grows, so I cant then hook in and allocate more vmalloc() space.

It seems like it would be sensible to let userspace allocate the memory 
and then mmap() that range, but I've been told this is a bad idea.

Whats the best approach here? With the buffers being large I dont really 
want to transmit them in tiny bits either.

-Ian

             reply	other threads:[~2010-09-13 16:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-13 15:51 Ian Molton [this message]
2010-09-14  6:52 ` Buffer allocation question Clemens Ladisch
2010-09-14 17:43   ` Ian Molton

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=4C8E4898.7090407@collabora.co.uk \
    --to=ian.molton@collabora.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    /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