From: harry <harry@hebutterworth.freeserve.co.uk>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: *** SPAM *** Re: [PATCH][2/17] USB virt 2.6 split driver---xenidc buffer resource provider
Date: Tue, 22 Nov 2005 12:14:50 +0000 [thread overview]
Message-ID: <1132661690.5956.24.camel@localhost.localdomain> (raw)
In-Reply-To: <5e9bc581e376b78ad3bbe5cb6d64819b@cl.cam.ac.uk>
On Tue, 2005-11-22 at 12:06 +0000, Keir Fraser wrote:
> On 22 Nov 2005, at 11:22, Muli Ben-Yehuda wrote:
>
> > Quoth Linus[1[:
> >
> > "vmalloc() is NOT SOMETHING YOU SHOULD EVER USE! It's only valid for
> > when you _need_ a big array, and you don't have any choice. It's slow,
> > and it's a very restricted resource: it's a global resource that is
> > literally restricted to a few tens of megabytes. It should be _very_
> > carefully used."
>
> He also says the correct fix is to not need a multi-page chunk in the
> first place. If you do, then you should pre-allocate. If that's
> impossible (e.g., you're a module) then you use vmalloc(). The page
> allocator does not attempt any compaction, so even if there is plenty
> of memory you may well not find a big contiguous extent.
I have a couple of small vmallocs which will be OK as kmallocs and the others I'm just vmalloc-ing a chunk and then splitting it up into a number of smaller resources anyway so I could kmalloc them individually instead.
> -- Keir
>
>
prev parent reply other threads:[~2005-11-22 12:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-21 13:18 [PATCH][2/17] USB virt 2.6 split driver---xenidc buffer resource provider harry
2005-11-21 20:18 ` Muli Ben-Yehuda
2005-11-21 21:30 ` Harry Butterworth
2005-11-22 10:55 ` Muli Ben-Yehuda
2005-11-22 11:11 ` harry
2005-11-22 11:12 ` Keir Fraser
2005-11-22 11:22 ` Muli Ben-Yehuda
2005-11-22 12:06 ` Keir Fraser
2005-11-22 12:14 ` harry [this message]
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=1132661690.5956.24.camel@localhost.localdomain \
--to=harry@hebutterworth.freeserve.co.uk \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=xen-devel@lists.xensource.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.