| To: | "David S. Miller" <davem@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH] Make xfrm subsystem optional |
| From: | Andi Kleen <ak@xxxxxxx> |
| Date: | Sat, 14 Jun 2003 20:32:32 +0200 |
| Cc: | ak@xxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <20030614.042636.74749587.davem@xxxxxxxxxx> |
| References: | <20030614093630.GB16993@xxxxxxxxxxxxx> <20030614.023843.78709528.davem@xxxxxxxxxx> <20030614101851.GA24170@xxxxxxxxxxxxx> <20030614.042636.74749587.davem@xxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
On Sat, Jun 14, 2003 at 04:26:36AM -0700, David S. Miller wrote: > 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 > it's not guaranteed you can still get two 32K continuous areas. You > could fall back to vmalloc I guess. > > Andi, you're getting rediculious. Add a xfrm_whatever_init() call > and allocate the table there. 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. -Andi |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: e1000 performance hack for ppc64 (Power4), Greg KH |
|---|---|
| Next by Date: | decorum, John S. Denker |
| Previous by Thread: | Re: [PATCH] Make xfrm subsystem optional, David S. Miller |
| Next by Thread: | decorum, John S. Denker |
| Indexes: | [Date] [Thread] [Top] [All Lists] |