Original Kernel compilation with performances degraded[NO PROCESS TO PROVE IT]

[Daniel]

Is it necessary to use all patches, or only thoses corresponding to be done after kernel date?
What is the reason of having patch witch are almost applied ?

D.

[Daniel]

3 patches were applied.
No better performace

D.

[curaga]

The squashfs patches were used to update the squashfs module, after the original kernel builds.

[Frank]

I've build all again : same result.

Confirmed. On standard TC 3.5 with standard TC compile tools, the distributed kernel source ("linux-2.6.33.3-patched.tbz2") plus the distributed kernel configuration file ("config-2.6.33.3-tinycore") do NOT generate the same binary kernel ("bzImage") that is distributed with TC.

Daniel, as you described previously, the generated kernel is larger (2296000 bytes) than the kernel that comes with TC (2294848 bytes). In addition, a "cmp -b -l [...] | wc -l" between the two kernels shows 2283120 differing bytes.

After applying the three squashfs patches that cooperated ("squashfs-warning.patch" did not), there were still 2283073 differing bytes.

Trying to apply the remaining (non-squashfs) patches showed that they HAD already been applied.

Gentlemen, the situation is a mess. You may wish to do some spring-cleaning while your collection of applied and non-applied patches is still halfway manageable.

[tinypoodle]

Couldn't the differing result be due to the fact that some of all involved tools have been updated since the repo kernel was compiled?

Once there is a difference of ~1KB I'd doubt that result of comparing compressed binaries by using 'cmp' could be of much relevance...

[Daniel]

Thanks for the test, Frank!

I stop my investigations and wait for what i have to do to have correct way of compiling (or patch ... etc).

I can make specific tests if necessary
Tell me!

Daniel.

[curaga]

As mentioned, it's expected to get a different binary. Both order of objects and any uninitialized fields can affect compression.

Try with any two files, tar cvzf test1.tgz a b; tar cvzf test2.tgz b a

[Daniel]

i'm not worring about crc or size!
But about performances!

Compilation can be made as anybody want!

But if link edition has not same results, it has to be ordered done!
Same for initialisations!

But i'm more thinking of a compilation / link optimisation option, or an unknown patch ...

D.

[gerald_clark]

There has been a lot of speculation and claims, but still not one bit of
documentation of any performance issues.

[Frank]

If you re-read the thread you will find that the performance issue was described on page 1. Daniel's Flash application in fullscreen mode takes 2.5 seconds with the original TC kernel, but takes 3 seconds with a rebuilt TC kernel -- all else being held equal. On page 2 you can find that the performance difference between original and rebuilt kernel is not an isolated "glitch," but is replicable.

[Daniel]

In order to test performances, you can use the Fps meter i describe before ...

you flash play it with original kernel, and compiled kernel ... see the differences!

D.

[tinypoodle]

So I let that flash thing run for about 1 minute and got fluctuation between 25-35 fps...
You mention a performance difference of 18% between 2 kernels, when with one and the same kernel it could be much higher, based on that...

[gerald_clark]

In order for measurements to be useful, you must know exactly what you are measuring.

[hiro]

Daniel have you tried tce-remove flash10?
My performance is skyrocketing now!

[Daniel]

Hiro,

No, i don't.
But that is not the problem!

With same configuration and changing only kernel, performances are not identical!
And i will absolutly need to compile kernel!

Thanks
Daniel.