lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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