Messages in this thread | | | Date | Fri, 28 Mar 2008 21:56:59 +0200 (EET) | From | "Ilpo Järvinen" <> | Subject | Re: [PATCH 1/7] [NET]: uninline skb_put, de-bloats a lot |
| |
On Thu, 27 Mar 2008, Matt Mackall wrote: > On Thu, 2008-03-27 at 17:54 -0700, Joe Perches wrote: > > On Thu, 2008-03-27 at 19:11 -0500, Matt Mackall wrote: > > > In the 486 era, when CPU performance was close to 1:1 with memory, > > > branches were more expensive than sequential memory fetches, and > > > registers were scarce, inlining made a fair amount of sense. > > > > > > But now we've moved very far away from that indeed: > > > > Systems have certainly improved but Linux is used in a > > wide variety of CPU Hz, memory & register architectures. > > > > Some of those systems haven't changed at all. > > It's true. In particular, 486s haven't changed at all since the 486 era. > What's changed is that people no longer run 486s to go fast, they run > them to save money. Saving memory is a win for those people.
I'd guess though that they won't get that big size saving because they probably have carefully tuned configs as well.
> The same goes for embedded systems. Saving memory is much higher on the > priority scale than performance. And the fact that saving memory on the > low end aligns very nicely with increasing performance on the high end > means that's the direction we're going.
Also if some TLB misses are avoided due to uninlining, it may well rebalance the equation (each config & scenario is quite unique though).
-- i.
| |