From: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Keshavamurthy, Anil S" <anil.s.keshavamurthy@intel.com>,
Andreas Kleen <ak@suse.de>,
linux-kernel@vger.kernel.org, gregkh@suse.de, muli@il.ibm.com,
asit.k.mallick@intel.com, suresh.b.siddha@intel.com,
arjan@linux.intel.com, ashok.raj@intel.com, shaohua.li@intel.com,
davem@davemloft.net, clameter@sgi.com
Subject: Re: [Intel-IOMMU 02/10] Library routine for pre-allocat pool handling
Date: Fri, 8 Jun 2007 15:18:03 -0700 [thread overview]
Message-ID: <20070608221803.GT17143@linux-os.sc.intel.com> (raw)
In-Reply-To: <20070608144207.07341ee7.akpm@linux-foundation.org>
On Fri, Jun 08, 2007 at 02:42:07PM -0700, Andrew Morton wrote:
> I'd say just remove the whole thing and use kmem_cache_alloc().
We will try that.
> Put much effort into removing the GFP_ATOMIC and using GFP_NOIO instead:
> there's your problem right there.
As these are called from interrupt handlers, we can't use GFP_NOIO.
> If for some reason you really can't do that (and a requirement for
> allocation-in-interrupt is the only valid reason, really) and if you indeed
> can demonstrate memory allocation failures with certain workloads then
> let's take a look at that. As I said, attaching a reserve pool to your
> slab cache might be a suitable approach. But none of these things are
I agree. We are better off with enhancing slab infrastructure for this, if
needed.
> magic: if memory allcoation failures or deadlocks or livelocks are
> demonstrable with the reserves absent, then they'll also be possible with
> the reserves present.
>
> Unless you use mempools, and can sleep.
next prev parent reply other threads:[~2007-06-08 22:21 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-06 18:56 [Intel-IOMMU 00/10] Intel IOMMU Support anil.s.keshavamurthy
2007-06-06 18:56 ` [Intel-IOMMU 01/10] DMAR detection and parsing logic anil.s.keshavamurthy
2007-06-06 18:57 ` [Intel-IOMMU 02/10] Library routine for pre-allocat pool handling anil.s.keshavamurthy
2007-06-07 23:27 ` Andrew Morton
2007-06-08 18:21 ` Keshavamurthy, Anil S
2007-06-08 19:01 ` Andrew Morton
2007-06-08 20:12 ` Keshavamurthy, Anil S
2007-06-08 20:40 ` Siddha, Suresh B
2007-06-08 20:44 ` Andrew Morton
2007-06-08 22:33 ` Christoph Lameter
2007-06-08 22:49 ` Keshavamurthy, Anil S
2007-06-08 20:43 ` Andreas Kleen
2007-06-08 20:55 ` Andrew Morton
2007-06-08 22:31 ` Andi Kleen
2007-06-08 21:20 ` Keshavamurthy, Anil S
2007-06-08 21:42 ` Andrew Morton
2007-06-08 22:17 ` Arjan van de Ven
2007-06-08 22:18 ` Siddha, Suresh B [this message]
2007-06-08 22:38 ` Christoph Lameter
2007-06-08 22:36 ` Christoph Lameter
2007-06-08 22:56 ` Andi Kleen
2007-06-08 22:59 ` Christoph Lameter
2007-06-09 9:47 ` Andi Kleen
2007-06-11 20:44 ` Keshavamurthy, Anil S
2007-06-11 21:14 ` Andrew Morton
2007-06-11 9:46 ` Ashok Raj
2007-06-11 22:16 ` Andi Kleen
2007-06-11 23:28 ` Christoph Lameter
2007-06-11 23:52 ` Keshavamurthy, Anil S
2007-06-12 0:30 ` Andrew Morton
2007-06-12 1:10 ` Arjan van de Ven
2007-06-12 1:30 ` Christoph Lameter
2007-06-12 1:35 ` Andrew Morton
2007-06-12 1:55 ` Arjan van de Ven
2007-06-12 2:08 ` Siddha, Suresh B
2007-06-13 18:40 ` Matt Mackall
2007-06-13 19:04 ` Andi Kleen
2007-06-12 0:38 ` Christoph Lameter
2007-06-11 21:29 ` Christoph Lameter
2007-06-11 21:40 ` Keshavamurthy, Anil S
2007-06-11 22:25 ` Andi Kleen
2007-06-11 11:29 ` Ashok Raj
2007-06-11 23:15 ` Keshavamurthy, Anil S
2007-06-08 22:32 ` Christoph Lameter
2007-06-08 22:45 ` Keshavamurthy, Anil S
2007-06-08 22:55 ` Christoph Lameter
2007-06-10 16:38 ` Arjan van de Ven
2007-06-11 16:10 ` Christoph Lameter
2007-06-06 18:57 ` [Intel-IOMMU 03/10] PCI generic helper function anil.s.keshavamurthy
2007-06-06 18:57 ` [Intel-IOMMU 04/10] clflush_cache_range now takes size param anil.s.keshavamurthy
2007-06-06 18:57 ` [Intel-IOMMU 05/10] IOVA allocation and management routines anil.s.keshavamurthy
2007-06-07 23:34 ` Andrew Morton
2007-06-08 18:25 ` Keshavamurthy, Anil S
2007-06-06 18:57 ` [Intel-IOMMU 06/10] Intel IOMMU driver anil.s.keshavamurthy
2007-06-07 23:57 ` Andrew Morton
2007-06-08 22:30 ` Christoph Lameter
2007-06-13 20:20 ` Keshavamurthy, Anil S
2007-06-06 18:57 ` [Intel-IOMMU 07/10] Intel iommu cmdline option - forcedac anil.s.keshavamurthy
2007-06-07 23:58 ` Andrew Morton
2007-06-06 18:57 ` [Intel-IOMMU 08/10] DMAR fault handling support anil.s.keshavamurthy
2007-06-06 18:57 ` [Intel-IOMMU 09/10] Iommu Gfx workaround anil.s.keshavamurthy
2007-06-08 0:01 ` Andrew Morton
2007-06-06 18:57 ` [Intel-IOMMU 10/10] Iommu floppy workaround anil.s.keshavamurthy
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=20070608221803.GT17143@linux-os.sc.intel.com \
--to=suresh.b.siddha@intel.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=anil.s.keshavamurthy@intel.com \
--cc=arjan@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=asit.k.mallick@intel.com \
--cc=clameter@sgi.com \
--cc=davem@davemloft.net \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=muli@il.ibm.com \
--cc=shaohua.li@intel.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.