This patches only compiles the xfrm subsystem in when any of the options using it are selected. This shrinks the text segment on an amd64 kernel by ~32k, data by ~6k, bss by ~33k, overall ~72K memory
I'm not going to apply this, sorry Andi. I want the freedom to use the XFRM layer for generic things at some point. How about working on making the xfrm layer more lean instead? :)
But in 2.7 surely right? When what happens you can easily make CONFIG_XFRM the default. This would give the 2.6 users an useful option. Also when you do use it generically you will hopefully discard
Also when you do use it generically you will hopefully discard some old code (like the rt cache?) which may make up for the additional bloat. But until that happens having both even when not needed d
In that case you could really apply the patch. It doesn't close any future options for you, just makes live a bit better for some users today. Allocating it at first lookup would be racy (would need
From: Andi Kleen <ak@xxxxxxx> Date: Sat, 14 Jun 2003 12:18:51 +0200 Allocating it at first lookup would be racy (would need a nasty spinlock at least). It may be possible at first policy setup, but i
Did you actually read what I wrote? Allocating on init is useless from the bloat perspective because it's 100% equivalent to an BSS allocation. If dynamic, you could allocate a "tiny" hash table or
I suspect dynamic growing at runtime would result in interesting SMP locking issues (suspect - i haven't studied the xfrm locking in detail yet) Also it has the same problem - 32K direct mapping allo