All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: David Gibson <david@gibson.dropbear.id.au>,
	<linuxppc-embedded@lists.linuxppc.org>
Cc: "David S. Miller" <davem@redhat.com>
Subject: Re: consistent_alloc() revisited
Date: Sat, 20 Jul 2002 17:28:30 +0200	[thread overview]
Message-ID: <20020720152830.1555@192.168.4.1> (raw)
In-Reply-To: <20020717012442.GA22786@zax>


>As far as I can tell there's no problem with get_free_pages() (or
>rather, alloc_pages()), except that we need to add GFP_ATOMIC to the
>flags if we're in interrupt context.
>
>The problems are in get_vm_area() which does a kmalloc() without
>GFP_ATOMIC and in map_page() which can sleep.

(Note do DaveM: this thread from linuxppc-embedded talks about
out consistent_alloc() functions used to get non-cacheable
DMA consistent memory for peripherials on the various non-PCI
type busses you can find on such embedded CPUs)

We can't rely on in_interrupt(). We can be called with a spinlock
held or on the VM path. In those cases, we need GFP_ATOMIC but
in_interrupt() won't be set.

I would rather pass a gfp_mask argument to consistent_alloc. I know
the pci_xxx version lacks that argument, I yet have to talk to DaveM
about it, in the meantime, it should be implemented as calling
consistent_alloc(..., GFP_ATOMIC).

I want the gfp argument to be passed since some drivers will want
a quite large pool to be allocated at insmod/kernel init time,
and I want to let those drivers to be able to sleep while VM
gets the pages back in this case instead of failing as they would
probably do with a GFP_ATOMIC on a machine that have been running
for some time.

Ben.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2002-07-20 15:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-16  2:13 consistent_alloc() revisited David Gibson
2002-07-16 14:09 ` Dan Malek
2002-07-16 14:58   ` Tom Rini
2002-07-16 15:23   ` Matt Porter
2002-07-16 15:27   ` Matt Porter
2002-07-17  1:24   ` David Gibson
2002-07-20 15:28     ` Benjamin Herrenschmidt [this message]
2002-07-21 13:26       ` David Gibson
2002-07-20 15:22 ` Benjamin Herrenschmidt
2002-07-21 13:23   ` David Gibson
  -- strict thread matches above, loose matches on Subject: below --
2002-07-16 16:14 Ralph Blach

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=20020720152830.1555@192.168.4.1 \
    --to=benh@kernel.crashing.org \
    --cc=davem@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=linuxppc-embedded@lists.linuxppc.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 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.