netdev - RE: [net-next PATCH 0/4] net: frag patchset for fixing LRU scalabilityissue

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B71F9@saturn3.aculab.com>
Date:	Wed, 24 Apr 2013 17:21:31 +0100
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Jesper Dangaard Brouer" <brouer@...hat.com>,
	"David S. Miller" <davem@...emloft.net>,
	"Hannes Frederic Sowa" <hannes@...essinduktion.org>
Cc:	<netdev@...r.kernel.org>, "Eric Dumazet" <eric.dumazet@...il.com>
Subject: RE: [net-next PATCH 0/4] net: frag patchset for fixing LRU scalabilityissue

> I have dropped the idea of doing "direct hash cleaning".  Instead I
> have simply choosen to solve the global LRU list problem, by making
> the LRU list be per CPU.

How can a per-cpu LRU list work?
I see two immediate problems:
- Ensuring the normal 'allocate' and 'free' are always done
  on the same cpu (free will need to remove items from any
  LRU list).
- Ensuring that there all the items aren't on the LRU lists
  of other cpus - meaning one can't be allocated.

The only way this could work is if the allocation limit
is also per-cpu and you can guarantee that the alloc and
free for any given item will always happen on the same cpu.

(alloc as in 'add to LRU list, free as in 'remove from LRU list).

	David