mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Dieter Nützel" <Dieter.Nuetzel@hamburg.de>
To: Oliver Xymoron <oxymoron@waste.org>
Cc: Robert Love <rml@tech9.net>, Andrea Arcangeli <andrea@suse.de>,
	Roger Larsson <roger.larsson@norran.net>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	ReiserFS List <reiserfs-list@namesys.com>
Subject: Re: [PATCH] Preemption Latency Measurement Tool
Date: Fri, 21 Sep 2001 00:51:48 +0200	[thread overview]
Message-ID: <20010920225130Z274687-760+14632@vger.kernel.org> (raw)
In-Reply-To: <Pine.LNX.4.30.0109201659210.5622-100000@waste.org>
In-Reply-To: <Pine.LNX.4.30.0109201659210.5622-100000@waste.org>

Am Freitag, 21. September 2001 00:03 schrieb Oliver Xymoron:
> On Thu, 20 Sep 2001, Dieter Nützel wrote:
> > Am Donnerstag, 20. September 2001 23:10 schrieb Robert Love:
> > > On Thu, 2001-09-20 at 04:21, Andrea Arcangeli wrote:
> > > > > You've forgotten a one liner.
> > > > >
> > > > >   #include <linux/locks.h>
> > > > > +#include <linux/compiler.h>
> > > >
> > > > woops, didn't trapped it because of gcc 3.0.2. thanks.
> > > >
> > > > > But this is not enough. Even with reniced artsd (-20).
> > > > > Some shorter hiccups (0.5~1 sec).
> > > >
> > > > I'm not familiar with the output of the latency bench, but I actually
> > > > read "4617" usec as the worst latency, that means 4msec, not 500/1000
> > > > msec.
> > >
> > > Right, the patch is returning the length preemption was unavailable
> > > (which is when a lock is held) in us. So it is indded 4ms.
> > >
> > > But, I think Dieter is saying he _sees_ 0.5~1s latencies (in the form
> > > of audio skips).  This is despite the 4ms locks being held.
> >
> > Yes, that's the case. During dbench 16,32,40,48, etc...
>
> You might actually be waiting on disk I/O and not blocked.
>
> Does your audio source depend on any files (eg mp3s) and if so, could they
> be moved to a ramfs? Do the skips go away then?

Good point.

I've copied one video (MP2) and one Ogg-Vorbis file into /dev/shm.
Little bit better but hiccup still there :-(

dbench 16
Throughput 25.7613 MB/sec (NB=32.2016 MB/sec  257.613 MBit/sec)
7.500u 29.870s 1:22.99 45.0%    0+0k 0+0io 511pf+0w

Worst 20 latency times of 3298 measured in this period.
  usec      cause     mask   start line/file      address   end line/file
 11549  spin_lock        1   678/inode.c         c01566d7   704/inode.c

c01566a0 T prune_icache
c01566d7 ..... <<<<<
c0156800 T shrink_icache_memory

  7395  spin_lock        1   291/buffer.c        c014151c   285/buffer.c

c0141400 T kupdate
c014151c ..... <<<<<
c0141610 T set_buffer_async_io

  7372  spin_lock        1   291/buffer.c        c01413e3   280/buffer.c

c0141290 T bdflush
c01413e3 ..... <<<<<
c0141400 T kupdate

  5702   reacqBKL        1  1375/sched.c         c0114d94   697/sched.c

c0114d60 T preempt_schedule
c0114d94 ..... <<<<<
c0114e10 T wake_up_process

  4744        BKL        0  2763/buffer.c        c01410aa   697/sched.c

c0141080 t sync_old_buffers
c01410aa ..... <<<<<
c01411b0 T block_sync_page

  4695  spin_lock        1   291/buffer.c        c014151c   280/buffer.c
  4551  spin_lock        1  1376/sched.c         c0114db3  1380/sched.c
  4466  spin_lock        1   547/sched.c         c0112fe4  1306/inode.c
  4464  spin_lock        1  1376/sched.c         c0114db3   697/sched.c
  4146   reacqBKL        1  1375/sched.c         c0114d94   842/inode.c
  4131  spin_lock        0   547/sched.c         c0112fe4   697/sched.c
  3900   reacqBKL        1  1375/sched.c         c0114d94   929/namei.c
  3390  spin_lock        1   547/sched.c         c0112fe4  1439/namei.c
  3191        BKL        0  1302/inode.c         c016f359   842/inode.c
  2866        BKL        0  1302/inode.c         c016f359  1381/sched.c
  2803   reacqBKL        0  1375/sched.c         c0114d94  1381/sched.c
  2762        BKL        0    30/inode.c         c016ce51    52/inode.c
  2633        BKL        0  2763/buffer.c        c01410aa  1380/sched.c
  2629        BKL        0  2763/buffer.c        c01410aa  1381/sched.c
  2466  spin_lock        1   468/vmscan.c        c0133c35   415/vmscan.c

*******************************************************

dbench 16 + renice artsd -20 works
GREAT!

*******************************************************

dbench 32 and above + renice artsd -20 fail

Writing this during dbench 32 ...:-)))

dbench 32 + renice artsd -20
Throughput 18.5102 MB/sec (NB=23.1378 MB/sec  185.102 MBit/sec)
15.240u 63.070s 3:49.21 34.1%   0+0k 0+0io 911pf+0w

Worst 20 latency times of 3679 measured in this period.
  usec      cause     mask   start line/file      address   end line/file
 17625  spin_lock        1   678/inode.c         c01566d7   704/inode.c

c01566a0 T prune_icache
c01566d7 ..... <<<<<
c0156800 T shrink_icache_memory

  9829  spin_lock        1   547/sched.c         c0112fe4   697/sched.c
  9186  spin_lock        1   547/sched.c         c0112fe4  1306/inode.c
  7447   reacqBKL        1  1375/sched.c         c0114d94   697/sched.c
  7097        BKL        1  1302/inode.c         c016f359   697/sched.c
  5974  spin_lock        1  1376/sched.c         c0114db3   697/sched.c
  5231        BKL        1  1437/namei.c         c014c42f   697/sched.c
  5192  spin_lock        0  1376/sched.c         c0114db3  1380/sched.c
  4992   reacqBKL        1  1375/sched.c         c0114d94  1381/sched.c
  4875  spin_lock        1   305/dcache.c        c0153acd    80/dcache.c
  4390        BKL        1   927/namei.c         c014b2bf   929/namei.c
  3616   reacqBKL        0  1375/sched.c         c0114d94  1306/inode.c
  3498  spin_lock        1   547/sched.c         c0112fe4   929/namei.c
  3427  spin_lock        1   547/sched.c         c0112fe4   842/inode.c
  3323        BKL        1  1302/inode.c         c016f359  1306/inode.c
  3165        BKL        1   452/exit.c          c011af61   697/sched.c
  3059  spin_lock        1   305/dcache.c        c0153acd    86/dcache.c
  3016        BKL        1   533/inode.c         c016d9cd  1306/inode.c
  2943        BKL        1  1302/inode.c         c016f359    52/inode.c
  2904  spin_lock        1   547/sched.c         c0112fe4  1439/namei.c

Thanks,
	Dieter

  reply	other threads:[~2001-09-20 22:51 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200109200758.f8K7wEG13675@zero.tech9.net>
2001-09-19 22:44 ` Robert Love
2001-09-20  1:40   ` Ignacio Vazquez-Abrams
2001-09-20  2:23     ` safemode
2001-09-20  1:13       ` David Lang
2001-09-20  2:57         ` Robert Love
2001-09-20  2:38     ` Robert Love
2001-09-20  6:31   ` Dieter Nützel
2001-09-20  6:31   ` Dieter Nützel
     [not found]   ` <20010920063143.424BD1E41A@Cantor.suse.de>
2001-09-20  6:41     ` Andrea Arcangeli
2001-09-20  7:57       ` Dieter Nützel
     [not found]       ` <200109200757.JAA60995@blipp.internet5.net>
2001-09-20 17:37         ` Roger Larsson
2001-09-20 21:29         ` Robert Love
2001-09-20 21:53           ` Dieter Nützel
2001-09-20 21:09       ` Robert Love
     [not found]       ` <20010920075751.6CA791E6B2@Cantor.suse.de>
2001-09-20  8:21         ` Andrea Arcangeli
2001-09-20 20:13           ` george anzinger
2001-09-20 20:38             ` Randy.Dunlap
2001-09-20 21:10         ` Robert Love
2001-09-20 21:35           ` Dieter Nützel
2001-09-20 22:03             ` Oliver Xymoron
2001-09-20 22:51               ` Dieter Nützel [this message]
2001-09-21  3:17               ` Robert Love
2001-09-21 15:48                 ` george anzinger
2001-09-22 21:09                   ` Dieter Nützel
2001-09-22 23:40                     ` safemode
2001-09-22 23:46                     ` Dieter Nützel
2001-09-23  0:15                     ` safemode
     [not found]                     ` <200109222340.BAA37547@blipp.internet5.net>
2001-09-23  0:38                       ` Roger Larsson
2001-09-23  1:42                         ` safemode
2001-09-23  3:02                       ` Robert Love
2001-09-23 16:43                         ` Roger Larsson
2001-09-23  0:42                     ` Dieter Nützel
2001-09-23  2:50                     ` Robert Love
2001-09-23  3:14                       ` george anzinger
2001-09-23  4:06                         ` Dieter Nützel
2001-09-23  2:54                     ` Robert Love
2001-09-27  0:02                       ` [reiserfs-list] " Dieter Nützel
2001-09-23  2:58                     ` Robert Love
2001-09-23  2:44                   ` Robert Love
2001-09-20 20:01   ` Tobias Diedrich
2001-09-20 20:27   ` Robert Love
2001-09-20 22:09     ` [PATCH] Preemption patch 2.4.9-ac12 Robert Love
2001-09-20 22:01   ` [PATCH] Preemption Latency Measurement Tool Robert Love
2001-09-22  3:57   ` Andre Pang
2001-09-22  6:10   ` Robert Love
2001-09-22  7:22     ` Andre Pang
2001-09-23  3:18       ` george anzinger
2001-09-23  3:21       ` Robert Love
2001-09-22 12:56     ` ksoftirqd? (Was: Re: [PATCH] Preemption Latency Measurement Tool) Roger Larsson
2001-09-22 13:14       ` Andrea Arcangeli
2001-09-22 20:51         ` Roger Larsson
2001-09-22 21:33           ` Andrea Arcangeli
2001-09-23  7:05     ` [PATCH] Preemption Latency Measurement Tool Robert Love
2001-09-23 12:03       ` Andre Pang
2001-09-23 18:31       ` Robert Love
     [not found] <200109202253.RAA21082@waste.org>
2001-09-20 23:15 ` Oliver Xymoron
2001-09-21  0:42   ` Roger Larsson
2001-09-21  1:03     ` Alan Cox
2001-09-21  1:22       ` Andrea Arcangeli
2001-09-21  1:51         ` Rik van Riel
2001-09-21  1:38       ` Roger Larsson
2001-09-21  1:53         ` Roger Larsson
2001-09-21  2:08           ` Roger Larsson
2001-09-21  2:29             ` Rik van Riel
2001-09-21 16:24       ` Jussi Laako
2001-09-21 16:36         ` Alan Cox
2001-09-21 18:46         ` Thomas Sailer
2001-09-22 10:30           ` Jussi Laako
2001-09-21 16:18     ` Stefan Westerfeld
2001-09-21 20:18       ` Dieter Nützel
2001-09-21 21:47       ` Robert Love
2002-04-09  5:23 [PATCH] preemption latency measurement tool Robert Love

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=20010920225130Z274687-760+14632@vger.kernel.org \
    --to=dieter.nuetzel@hamburg.de \
    --cc=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oxymoron@waste.org \
    --cc=reiserfs-list@namesys.com \
    --cc=rml@tech9.net \
    --cc=roger.larsson@norran.net \
    /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

all inboxes | Powered by JetHome®