| To: | Andi Kleen <ak@xxxxxxx> |
|---|---|
| Subject: | Re: [RFC] TCP Vegas for 2.6 |
| From: | Nivedita Singhvi <niv@xxxxxxxxxx> |
| Date: | Mon, 08 Mar 2004 13:51:17 -0800 |
| Cc: | Stephen Hemminger <shemminger@xxxxxxxx>, linux-net <linux-net@xxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx |
| In-reply-to: | <20040308213646.GH26401@xxxxxxxxxxxxx> |
| References: | <20040308130454.0442c04d@xxxxxxxxxxxxxxxxxxxxx> <20040308212156.GE26401@xxxxxxxxxxxxx> <20040308133009.1e068199@xxxxxxxxxxxxxxxxxxxxx> <20040308213646.GH26401@xxxxxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 |
Andi Kleen wrote: CONFIG options are of no use vendors who need to ship binary kernels. But they are real handy to developers and benchmarking folks who are trying to evaluate their impact and need to compare with/without :) I can well see a vendor trading scalability for experimental non standard TCP algorithms that tend to be disabled anyways.Or allocating separately if you prefer that. In theory it may be even possible to change the slab cache size at runtime, but that could get tricky. It would be nice to minimize this if possible, but keep in mind that dynamic allocation of memory (and freeing it) is among the costliest performance hits we take.. thanks, Nivedita |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [RFC] TCP Vegas for 2.6, Stephen Hemminger |
|---|---|
| Next by Date: | Re: 2.6.4-rc1 + hp100 EISA, not working, Marc Zyngier |
| Previous by Thread: | Re: [RFC] TCP Vegas for 2.6, jamal |
| Next by Thread: | Re: [RFC] TCP Vegas for 2.6, David S. Miller |
| Indexes: | [Date] [Thread] [Top] [All Lists] |