| To: | Ganesh Venkatesan <ganesh.venkatesan@xxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000 |
| From: | Andrew Morton <akpm@xxxxxxxx> |
| Date: | Wed, 18 May 2005 13:42:50 -0700 |
| Cc: | christoph@xxxxxxxxxxx, davem@xxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, shai@xxxxxxxxxxxx |
| In-reply-to: | <5fc59ff305051808558f1ce59@mail.gmail.com> |
| References: | <Pine.LNX.4.62.0505171854490.20408@graphe.net> <20050517190343.2e57fdd7.akpm@osdl.org> <Pine.LNX.4.62.0505171941340.21153@graphe.net> <20050517.195703.104034854.davem@davemloft.net> <Pine.LNX.4.62.0505172125210.22920@graphe.net> <20050517215845.2f87be2f.akpm@osdl.org> <5fc59ff305051808558f1ce59@mail.gmail.com> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
Ganesh Venkatesan <ganesh.venkatesan@xxxxxxxxx> wrote: > > On 5/17/05, Andrew Morton <akpm@xxxxxxxx> wrote: > > I think the e1000 driver is being a bit insane there. I figure that > Do you mean insane to use vmalloc? > > > sizeof(struct e1000_buffer) is 28 on 64-bit, so even with 4k pagesize we'll > > always succeed in being able to support a 32k/32 = 1024-entry Tx ring. > > > > Is there any real-world reason for wanting larger ring sizes than that? > > > > > We have had cases where allocation of 32K of memory (via kmalloc) fails. > Are you sure? The current page allocator will infinitely loop until success for <=32k GFP_KERNEL allocations - the only way it can fail is if the calling process gets oom-killed. |
| Previous by Date: | Re: [PATCH] Super TSO, David S. Miller |
|---|---|
| Next by Date: | Re: 2.6.12-rc4-mm2 - sleeping function called from invalid context at mm/slab.c:2502, Herbert Xu |
| Previous by Thread: | Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000, Ganesh Venkatesan |
| Next by Thread: | [PATCH] e1000: NUMA aware allocation of descriptors V2, Christoph Lameter |
| Indexes: | [Date] [Thread] [Top] [All Lists] |