[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070703121806.5327d232@freepuppy.localdomain.hemminger.net>
Date: Tue, 3 Jul 2007 12:18:06 -0700
From: Stephen Hemminger <shemminger@...ux-foundation.org>
To: netdev@...r.kernel.org
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/12] use a dynamic pool of sk_buffs to keep up with
fast targets
On Tue, 3 Jul 2007 13:45:33 -0500
Matt Mackall <mpm@...enic.com> wrote:
> On Mon, Jul 02, 2007 at 09:40:36PM -0700, David Miller wrote:
> > From: Andrew Morton <akpm@...ux-foundation.org>
> > Date: Mon, 2 Jul 2007 21:36:36 -0700
> >
> > > My initial thought is that if there is a legitimate need for this
> > > new capability then it should be made available to other parts of
> > > the kernel rather than being private to the AEO driver.
> >
> > Absolutely.
> >
> > We even used to have something like this on a per-cpu basis but using
> > generic SLAB is so much better for caching and NUMA that we got rid of
> > that.
> >
> > Every sk_buff private "quicklist" pool implementation you
> > see should essentially be NAK'd from the get go, it's
> > meaningless and if it's really needed one should investigate
> > why SKB allocations become such a problem instead of papering
> > over the issue. :-)
>
> This is in the VM write-back path. SLAB is insufficient to avoid
> deadlock.
>
Then where is the code to drain your pool back to the normal pool.
The problem with private pools is that they work great for benchmarks
and if that is the only code in the system. But they suck if other
code needs to run. How do you keep your private stash from running
the network device out of memory to receive packets?
--
Stephen Hemminger <shemminger@...ux-foundation.org>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists