2.6.x kernel sluggish behavior

2.6.x kernel sluggish behavior

[Lenar Lõhmus]

Hi.

Overall I really like the performance and smoothness of 2.6.x kernels,
but there has been always one problematic situation.

It's debian here with X/KDE running. The problem manifests itself
when one launches acroread-plugin in Mozilla or Mozilla-based browser. 
Whatever
is the reason, but when acroread is launched as browser plugin, it makes
system quite sluggish. X process starts to consume about 70% of cpu time 
continuosly.

That would not be a problem usually, but in this case system really 
feels like hanging
and stopping. Mouse cursor on screen stops and jumps and does other neat 
tricks.
Drawing of pages in acroread is extremely slow. Its very very bad when 
loaded document is some kind
of marketing brochure full of pictures/backgrounds etc... Nothing of 
this when acroread is being run as
standalone app.

Even more. This system has several terminals connected to it, and all of 
them show
same sluggish behavior same time. So it's not like X-server process 
running on system
is too busy to interact with mouse or draw on screen.

This behavior stops when the window with acroread is closed (or back 
button pressed when one
can direct mouse cursor to that button which as you can believe is very 
hard in this case).

I think it's definetely a scheduler problem (although caused by 
application bug).

You propably need more information. Just ask. I'm happy to help to get 
this annoying
problem disappear.

Lenar

Re: 2.6.x kernel sluggish behavior

[William Lee Irwin III]

On Wed, May 26, 2004 at 04:29:58PM +0300, Lenar L?hmus wrote:
> Overall I really like the performance and smoothness of 2.6.x kernels,
> but there has been always one problematic situation.
> It's debian here with X/KDE running. The problem manifests itself
> when one launches acroread-plugin in Mozilla or Mozilla-based browser. 
> Whatever is the reason, but when acroread is launched as browser
> plugin, it makes system quite sluggish. X process starts to consume
> about 70% of cpu time continuosly.
> That would not be a problem usually, but in this case system really 
> feels like hanging and stopping. Mouse cursor on screen stops and
> jumps and does other neat tricks.
> Drawing of pages in acroread is extremely slow. Its very very bad when 
> loaded document is some kind of marketing brochure full of
> pictures/backgrounds etc... Nothing of this when acroread is being
> run as standalone app.

What kernel version is this? Could you try with 2.6.6-mm4 if it was
less recent than that?


On Wed, May 26, 2004 at 04:29:58PM +0300, Lenar L?hmus wrote:
> Even more. This system has several terminals connected to it, and all of 
> them show same sluggish behavior same time. So it's not like X-server
> process running on system is too busy to interact with mouse or draw
> on screen.
> This behavior stops when the window with acroread is closed (or back 
> button pressed when one can direct mouse cursor to that button which
> as you can believe is very hard in this case).
> I think it's definetely a scheduler problem (although caused by 
> application bug).
> You propably need more information. Just ask. I'm happy to help to get 
> this annoying problem disappear.

Some instrumentation is likely in order. 2.6.6-mm4 has schedstats,
which you should log to get us enough information to do something about
this performance problem. Logs of vmstat, top, and snapshots of kernel
profiles, /proc/vmstat, and /proc/meminfo may also help.


-- wli

Re: 2.6.x kernel sluggish behavior

[Con Kolivas]

On Wed, 26 May 2004 11:29 pm, Lenar Lõhmus wrote:
> Hi.

Hello

> Overall I really like the performance and smoothness of 2.6.x kernels,

Good to hear.

> but there has been always one problematic situation.
>
> It's debian here with X/KDE running. The problem manifests itself
> when one launches acroread-plugin in Mozilla or Mozilla-based browser.

A known case.

> I think it's definetely a scheduler problem (although caused by
> application bug).

This was one of my test cases for applications designed in a certain way that 
makes them prone to priority inversion. I tried extremely hard to find a 
workaround within the kernel and failed to do so. It only manifests with the 
acroread plugin in a gecko browser on uniprocessor, and seems to be some 
interaction within some gdk library if I recall correctly. Look through the 
kernel archives for my description of an earlier version of blender that 
exhibited this same problem. I suspect it's actually the binary only acroread 
and not the gdk library at fault. My solution was to simply make all .pdf 
files launch acroread separately.

Generic solutions for tackling priority inversion prone application designs 
from within the kernel are expensive, and the best solution is to fix the 
application. No doubt a differently designed scheduler would be less prone to 
this particular interaction, but priority inversion is a "feature" of any 
dynamic priority design scheduler to some degree and it is the particular 
application that may or may not hit the resonant frequency (as I like to 
think of it) of each scheduler.

Con

Re: 2.6.x kernel sluggish behavior

[Lenar Lõhmus]

William Lee Irwin III wrote:

>What kernel version is this? Could you try with 2.6.6-mm4 if it was
>less recent than that?
>  
>
Right now it happens with 2.6.5-mm5. It has happened with all 
2.6.x(-mmY) I've tried. But as it seems
after reading Con's reply - this is known problem. So I won't send any 
vmstat/schedstat outputs unless
explicitly requested.

Although I agree with Con, that acroread/gecko should be fixed (because 
in-kernel
solution for this problem doesn't exist/is hard to do) some measures 
should still be implemented kernel-side
to at least soften the effects (it's kind of DoS for servers having 
acroread plugin installed and there
might be other apps/ways to trigger this although not known today).

Lenar