Ruby performance degraded on custom kernel

Hello list,

I have a rather odd question regarding ruby’s performance on a system
with a vanilla kernel from kernel.org version 2.6.18.1.

I have two identical systems.
One system has a minimal debian etch system installed which I use as a
host.
The other system is using a vanilla kernel from kernel.org.

The ruby installed is 1.8.5 patchlevel 2.

The ruby interpreter is 50% slower on the vanilla kernel system. Is also
uses a lot more CPU.

So I wonder if there are any kernel parameters that you know about that
could affect the performance of the ruby interpreter?

Any other ideas would be greatly appreciated.

Cheers,
Henrik

Henrik Z. wrote:

The ruby installed is 1.8.5 patchlevel 2.
Henrik
Well … I’m not sure off the top of my head what it could be, but if
one system is pure Etch and the other is pure Etch with identical
hardware, but you’ve only substituted the kernel from kernel.org, I’d
say it’s something that Debian has patched in the kernel that’s
preventing a problem. :slight_smile:

What’s the goal here? Is there something in the kernel.org kernel you
can’t do with Etch? What sort of script is the Ruby interpreter
running? It seems unlikely unless you’re doing something strange that
the Ruby interpreter would spend a lot of time dealing with the kernel.
If you have “top” running, is the overall CPU time “user”, “system” or
“nice”? Something else, like “irq” or “softirq”?

I’d put this one in the class of, “Doctor, it hurts when I do this.”

“OK, then don’t do that.”

:wink:

Thanks for your response.

Sorry, I wasn’t that clear with the environment. I’m building an
embedded system so I cannot use the debian install on the other system.

Either way, its no problem anymore. I solved it and it’s kinda
embarrassing. When I did a stress test with C code only I noticed the
same slowdown. I then noticed that the CPU somehow had degraded itself
to 1/3 of its speed…

Weee