public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: Lenar L?hmus <lenar@vision.ee>
Cc: Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.x kernel sluggish behavior
Date: Wed, 26 May 2004 07:05:13 -0700	[thread overview]
Message-ID: <20040526140513.GB2764@holomorphy.com> (raw)
In-Reply-To: <40B49BD6.7050202@vision.ee>

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

  reply	other threads:[~2004-05-26 14:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-26 13:29 2.6.x kernel sluggish behavior Lenar Lõhmus
2004-05-26 14:05 ` William Lee Irwin III [this message]
2004-05-26 16:05   ` Lenar Lõhmus
2004-05-26 14:46 ` Con Kolivas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040526140513.GB2764@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=lenar@vision.ee \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox