add a config option for -Os compilation

The thing is, that in fact kernel optimization is not that important.

The goal of kernel is to provide framework for applications to the
job well. I wasn't doing any kernels measurements - since kernel docs are saying that -O2 is the standard. And it is really hard to measure kernel only perfomance. (And it is rather pointless - I'm not going to sell linux kernel ;-)))

But indeed I was testing my application on embedded system with 16K
L1 cache. Results were pretty predictable: gcc 2.95.3 + -Os was giving some (around 2-3%) performance improvements, while 2.95.3 + -O[23] and 3.2.3 with any optimization were giving aprox. the same times. (App is bloated with third-party libraries, C++ and threads. Save God I have killed all exceptions - they were really really really slow on target system.)

But on other side - since embedded systems are not that overclocked
as high-end toys - cache miss is not that painful. As of docs, NatSemi Geode@266MHz cache miss costs exactly 266/66 == 4 cycles.

Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--
  "... and for $64000 question, could you get yourself vaguely
     familiar with the notion of on-topic posting?"
				-- Al Viro @ LKML

I doubt anyone using linux for routing would agree with you.

Wichert.

Wichert Akkerman <[email protected]>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

OK, so the applications are limited to /sbin/iptables, /sbin/route, /bin/ netstat, and maybe dhcpd and/or zebra. They're still applications, even if they end up invoking a lot of kernel resources on their behalf.

/sbin/iptables and /sbin/route are merely configuration interfaces to the kernel proper, not really familiar with netstat - but as far as I know all it does is dumps kernel runtime configuration and statistics. That's 3 utilities which are no way apps - just interfaces. Now dhcpd is an app and zebra is an app - but they are still mainly kernel oriented. The first 3 depend only on kernel speed and the next 2 depend mostly on kernel speed. I'd say you just proved how important kernel optimilization is for routers.

Cheers,
MaZe.

And we had a flame-fest a while ago about poll/epoll/etc and how optimizing that is important for some applications., and discussions of how CPU scheduling affects desktop applications, and how different I/O schedulers matter to databases, and....

My point was that the kernel is there for the application's benefit (otherwise we could have just said 'echo "main() { for(;;){}}" > linux.c' and been done with it), and just because the iptables or route command say "do this" and return, and the kernel is still "doing this" weeks later, doesn't change the fact that it's happening at the application's request (although you *are* correct that the tuning and optimization concerns are different).