[lkml]   [2010]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 03/13] jump label v9: x86 support
On Thu, Jun 10, 2010 at 05:37:42PM +0200, Ingo Molnar wrote:
> > [...] It costs you in some benchmarks. [...]
> Microbenchmarks mostly, see below.

I didn't make these decisions, but I assume who made them had good reasons
and enough data on larger benchmarks too.

> > A much better to get smaller kernel images is to do more __cold annotations
> > for slow paths. Newer gcc will then simply only do -Os for these functions.
> That's an opt-in method and we cannot reach the kinds of 30% code size
> reductions that -Os can achieve. Most code in the kernel is not cache-hot,
> even on microbenchmarks.

Maybe, maybe not. But yes it can be approached from both ways.

Personally I would prefer to simply write less bloated code to get
code reductions. Simpler code is often faster too.

> A much better model would be to actively mark hot codepaths with a __hot
> attribute instead. Then the code size difference can be considered on a case
> by case basis.

Yes that works too for those who still use -Os.

e.g. marking the scheduler and a few mm hot paths this way would certain make sense.

> And where GCC produces indefensibly crap code there GCC needs to be fixed.
> Crap code often increases size so the fix would increase the efficiency of
> -Os.

In some cases agreed, but common cases it's really: you asked for the smallest
you got it, even if it's slow. It's not -Odwim.

One standard example here is a division by constant. The shortest way is
using DIVI/IDIV if it's not 2^n and small enough, but it's really quite slow
in hardware. If you spend a few more bytes you can do much better for a wide
range of constants.

Most likely we would need a new -O flag to avoid such cases.

BTW I experimented with marking a few common cases like this (e.g. time unit
conversion) hot, but gcc currently has trouble with __hot on inlines. So you
would always need to mark the caller.


-- -- Speaking for myself only.

 \ /
  Last update: 2010-06-10 18:27    [W:0.075 / U:0.080 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site