All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J.A. Magallón" <jamagallon@ono.com>
To: Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: Finding what is stuck...
Date: Thu, 4 Sep 2008 01:00:43 +0200	[thread overview]
Message-ID: <20080904010043.408b3f03@one.home> (raw)
In-Reply-To: <20080901170812.2c3b041b@infradead.org>

On Mon, 1 Sep 2008 17:08:12 -0700, Arjan van de Ven <arjan@infradead.org> wrote:

> On Tue, 2 Sep 2008 02:04:47 +0200
> "J.A. Magallón" <jamagallon@ono.com> wrote:
> 
> > Hi all...
> > 
> > I'm running 2.6.27-rc5-git2 on an Aspire One.
> > The system is in general pretty responsive, but sometimes it just gets
> > totally stuck. Even the mouse stops. 
> > 
> > It looks related to disk (SSD) access, but I'm not totally sure.
> > Is there any way to find what is getting stuck ? I know that SSDs can
> > be slow on write, I don't mind if the system is faster or slower
> > (it's small :))), but if the speed is constant. That occasional
> > pauses are strange, like if SSD flushing gets stuck on BKL
> > (I know, no idea about what I talk...).
> > 
> > I'm using ext3 fs, noop iosched. But as I say, I'm not sure that the
> > disk writes are the culprit.
> > 
> > Any idea about how to find this ?
> 
> Have you tried to run "latencytop"?
> (you need to enable this in the kernel config as well)
> 
> it tends to (for me at least) point out very well where stalls happen,
> or at least, what the system is doing when they happen.
> 
> (hint: make sure you do "make install" before running it)
> 

These are some shots of latencytop while working. I copied the screen
when I saw any very high timing...

Cause                                                Maximum     Percentage
Walking directory tree                            790.2 msec         10.6 %
Scheduler: waiting for cpu                         40.5 msec         38.5 %

fsync() on a file                                 3191.6 msec         36.7 %
Reading EXT3 directory                            1553.3 msec          3.9 %
EXT3: Waiting for journal access                  1518.7 msec          3.8 %
Deleting an inode                                 657.5 msec          1.7 %
EXT3: Looking for file                            576.3 msec          1.4 %
Writing a page to disk                            363.0 msec          6.1 %
call_usermodehelper_exec request_module __sock_cre 69.4 msec          0.2 %
Scheduler: waiting for cpull                       28.0 msec         18.9 %
Page fault                                          7.9 msec          0.3 %

fsync() on a file                                 8843.7 msec         81.8 %
Writing a page to disk                            1548.6 msec          2.9 %
EXT3: Waiting for journal access                  356.5 msec          1.1 %
Scheduler: waiting for cpu                         40.6 msec          6.0 %

EXT3: Waiting for journal access                  6153.6 msec         17.2 %
fsync() on a file                                 4902.7 msec         53.5 %
Writing a page to disk                            3487.2 msec          9.8 %
Writing buffer to disk (synchronous)              2288.7 msec          4.6 %
synchronous write                                 1320.6 msec          2.6 %
Truncating file                                   302.6 msec          0.6 %
Page fault                                        290.5 msec          0.6 %
Scheduler: waiting for cpu                         13.4 msec          4.5 %
Waiting for event (select)                          5.0 msec          5.0 %

Deleting an inode                                 5584.7 msec         27.5 %
Writing a page to disk                            829.2 msec          5.4 %
fsync() on a file                                 265.1 msec         11.2 %
Scheduler: waiting for cpu                         37.2 msec         11.5 %
stat() operation                                    5.6 msec          0.1 %
Page fault                                          5.5 msec          0.2 %
Waiting for event (select)                          5.0 msec         39.8 %
Waiting for event (poll)                            5.0 msec          2.5 %
synchronous write                                   4.2 msec          0.0 %

All look fs access:

one:~# df
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/sda1     ext3    6.9G  3.7G  3.2G  55% /
tmpfs        tmpfs    246M   12K  246M   1% /tmp
/dev/mmcblk0p1
              ext3    1.9G   35M  1.8G   2% /store

I will try mounting root as ext2, to rule out jorunaling...

TIA

-- 
J.A. Magallon                       \                     Software is like sex:
                                     \               It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux kernel 2.6.23-jam01,  gcc version 4.2.2 20070909

  parent reply	other threads:[~2008-09-03 23:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-02  0:04 Finding what is stuck J.A. Magallón
2008-09-02  0:08 ` Arjan van de Ven
2008-09-02  0:12   ` J.A. Magallón
2008-09-03 23:00   ` J.A. Magallón [this message]
2008-09-03 23:50     ` Arjan van de Ven
2008-09-02  1:53 ` Jan Knutar
  -- strict thread matches above, loose matches on Subject: below --
2008-09-02  9:34 Alan Jenkins

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=20080904010043.408b3f03@one.home \
    --to=jamagallon@ono.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.