Kernel 2.6 size increase - get_current()?
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 24 lines · Bernardo Innocenti
Quoted 10 lines · Christoph Hellwig
Quoted 3 lines · David S. Miller
Drivers weren't audited much, and there's a lot of boneheaded stuff in this area. But these should be mostly identical to what would happen on the 2.4.x side
Please read the original message again - he stated that every single module in
fs/got alot bigger - if it gets smaller or at least the same size as 2.4 it's clearly a sign of inlines gone mad in the filesystem/VM code and we need to look at that. If not we have to look elsewhere.I have my humbling opinion:
In 2.4.20 (m68knommu):
-------------------------------------------------------------------------
#define current_current_task
-------------------------------------------------------------------------In 2.6.0-test1 (m68knommu):
-------------------------------------------------------------------------
static inline structtask_struct*get_current(void){
[cut]
Quoted 3 lines
}
static inline structthread_info*current_thread_info(void){
[cut]
Quoted 6 lines
}
-------------------------------------------------------------------------This takes 18*11 = 198 bytes just for invoking the 'current' macro so many times.
Just curious.
Is there any way to guess inline from inline?
I mean 'inline' which means 'this has to be inlined or it will
break' and 'inline' which means 'inline this please - it adds only 10k of code bloat and improve performance in my suppa-puppa-bench by 0.000001%!'
Strictly speaking - separate 'inline' to 'require_inline' and
'better_inline'.
So people who really care about image size - can turn
'better_inline' into void, without harm to functionality.
Actually I saw real performance improvements on my Pentium MMX 133
(it has $i16k+$d16k of caches I beleive) when I was cutting some of inlines out. and I'm not talking about (cache poor) embedded systems...
Quoted 11 lines · Ihar \"Philips\" Filipau
I mean 'inline' which means 'this has to be inlined or it will
break' and 'inline' which means 'inline this please - it adds only 10k of code bloat and improve performance in my suppa-puppa-bench by 0.000001%!'Strictly speaking - separate 'inline' to '
require_inline' and
'better_inline'.
So people who really care about image size - can turn
'better_inline' into void, without harm to functionality.
Actually I saw real performance improvements on my Pentium MMX 133
(it has $i16k+$d16k of caches I beleive) when I was cutting some of inlines out. and I'm not talking about (cache poor) embedded systems...
Which inlines? Let the list know
--
vda
In article <[email protected]>, Ihar \"Philips\" Filipau <[email protected]> wrote:
| Just curious. | | Is there any way to guess inline from inline? | | I mean 'inline' which means 'this has to be inlined or it will | break' and 'inline' which means 'inline this please - it adds only 10k | of code bloat and improve performance in my suppa-puppa-bench by 0.000001%!' | | Strictly speaking - separate 'inline' to 'require_inline' and | 'better_inline'. | So people who really care about image size - can turn | 'better_inline' into void, without harm to functionality. | Actually I saw real performance improvements on my Pentium MMX 133 | (it has $i16k+$d16k of caches I beleive) when I was cutting some of | inlines out. and I'm not talking about (cache poor) embedded systems...
Actually you have a very diferent CPU to memory bandwidth ratio than a processor manufactured in this millenium. I use a system like that for test, but please don't optimize for it!
Speculation of the day: I suspect that on some laptops which run seriously slower when on battery, the CPU/memory speed changes enough that you could see and measure better performance with a 'slow' and a 'fast' kernel.
Speculation, since I'm sure the gain would be down in the noise, one of those 'difference without a distinction' things.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.