public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: "David S. Miller" <davem@redhat.com>
Cc: dan@embeddededge.com, hozer@drgw.net,
	linux-kernel@vger.kernel.org, groudier@free.fr, mattl@mvista.com
Subject: Re: pci_alloc_consistent from interrupt == BAD
Date: Fri, 18 Jan 2002 21:29:49 +0000	[thread overview]
Message-ID: <20020118212949.H2059@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20020118130209.J14725@altus.drgw.net> <3C4875DB.9080402@embeddededge.com> <20020118.123221.85715153.davem@redhat.com>
In-Reply-To: <20020118.123221.85715153.davem@redhat.com>; from davem@redhat.com on Fri, Jan 18, 2002 at 12:32:21PM -0800

On Fri, Jan 18, 2002 at 12:32:21PM -0800, David S. Miller wrote:
> The ARM and PPC ports could set __GFP_HIGH in their page table
> allocation calls when invoked via pci_alloc_consistent, and this is
> the change I suggest they make.  It is a trivial fix whereas backing
> out this ability to call pci_alloc_consistent from interrupts is not
> a trivial change at all.

ARM will get fixed some way if and when it becomes a requirement to fix
it.  "requirement" here is defined by someone wanting to use such a
driver on an ARM system.  Currently, there is no call for it, so there's
not much point in implementing it.

However, if it becomes easy to implement without impacting the code too
much, then it will get fixed in due coarse.  The problem currently is
that there is no way for the page table allocation functions to know
that they should be using atomic and emergency pool memory allocations.

Its a balance of pain vs gain.  Pain is currently high, gain is currently
zero.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


  reply	other threads:[~2002-01-18 21:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-18 19:02 pci_alloc_consistent from interrupt == BAD Troy Benjegerdes
2002-01-18 19:22 ` Dan Malek
2002-01-18 20:32   ` David S. Miller
2002-01-18 21:29     ` Russell King [this message]
2002-01-18 21:33       ` David S. Miller
2002-01-18 21:42         ` Russell King
2002-01-18 21:46       ` Dan Malek
2002-01-18 21:55         ` Russell King
2002-01-18 22:13           ` Dan Malek
2002-01-18 21:43     ` Dan Malek
2002-01-18 20:50   ` Gérard Roudier
     [not found]   ` <mailman.1011386221.24072.linux-kernel2news@redhat.com>
2002-01-21 23:52     ` Pete Zaitcev
2002-01-22  0:08       ` David S. Miller
2002-01-22  0:20         ` Pete Zaitcev
2002-01-18 20:21 ` Gérard Roudier
2002-01-18 20:38   ` David S. Miller
2002-01-18 21:07     ` Gérard Roudier
2002-01-18 21:13       ` David S. Miller
  -- strict thread matches above, loose matches on Subject: below --
2002-01-19 17:21 David Brownell

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=20020118212949.H2059@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=dan@embeddededge.com \
    --cc=davem@redhat.com \
    --cc=groudier@free.fr \
    --cc=hozer@drgw.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mattl@mvista.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