Re: [PATCH] Preemption Latency Measurement Tool

[safemode <safemode@speakeasy.net>]

ok. The preemption patch helps realtime applications in linux be a little 
more close to realtime.  I understand that.  But your mp3 player shouldn't 
need root permission or renicing or realtime priority flags to play mp3s.  To 
test how well the latency patches are working you should be running things 
all at the same priority.  The main issue people are having with skipping 
mp3s is not in the decoding of the mp3 or in the retrieving of the file, it's 
in the playing in the soundcard.  That's being affected by dbench flooding 
the system with irq requests.  I'm inclined to believe it's irq requests 
because the _only_ time i have problems with mp3s (and i dont change priority 
levels) is when A. i do a cdparanoia -Z -B "1-"    or dbench 32.   I bet if 
someone did these tests on scsi hardware with the latency patch, they'd find 
much better results than us users of ide devices.  

even i dont get any skips when i run the player at nice -n -20.   That 
doesn't tell you much about the preemption patch though.  And it doesn't tell 
you about performance when you dont give linux the chance to do what it does, 
 multitask.  That's where the latency patch is directed at improving, i 
think.  




On Saturday 22 September 2001 17:09, Dieter Nützel wrote:
> Am Freitag, 21. September 2001 17:48 schrieb george anzinger:
> > Robert Love wrote:
> > > On Thu, 2001-09-20 at 18:51, Dieter Nützel wrote:
> > > > > 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 :-(
> > >
> > > As I've been saying, the problem really shouldn't be disk I/O.  I would
> > > think (and really hope) the readahead code can fit a little mp3 in
> > > memory.  Even if not, its a quick read to load it.  The continued blips
> > > you see are caused by something, well, continual :)
> >
> > Are you running your application at some real time priority?  I suspect
> > that, when dbench starts, it floods the system with a lot of new tasks
> > and the system must visit each one until it gets back to your ap.  Nice
> > will only do so much here.  Real time priority is the way to go.
> > Attached are a couple of small programs to help here.  "rt" runs a given
> > ap at a given priority.  I.e. > rt 10 foo, runs foo at priority 10.
> > (There are more options, try rt -h.)  getrt reports the priority of a
> > task.  If you do something like > rt 10 bash   everything you run from
> > the new bash prompt will be at priority 10.  You must be root to run rt
>
> Yes, I do like I've posted in all the related threads.
>
> Here is some more input for you. I hope it could help nail it down.
>
> Regards,
> 	Dieter
>
> BTW I'll now switching to 2.4.10-pre14
>
> SunWave1#time tar xIf /Pakete/Linux/linux-2.4.9.tar.bz2
> 34.570u 5.350s 0:47.84 83.4%    0+0k 0+0io 295pf+0w
>
> I "hear" some have disk activities (disk trashing).
>
> SunWave1#sync
>
> Runs for ages!!!
>
> User	 CPU  0%
> System	 CPU  0%
> Idle	 CPU 99%
>
> So where did it wait???
>
> Here comes what latencytimes show:
>
> Worst 20 latency times of 5061 measured in this period.
>   usec      cause     mask   start line/file      address   end line/file
> 322263   reacqBKL        1  1375/sched.c         c01138b4   697/sched.c
> 216174        BKL        1    30/inode.c         c016b971    52/inode.c
> 158328        BKL        9   742/block_dev.c     c0144d51   697/sched.c
>  66975        BKL        1  1101/super.c         c014250d   697/sched.c
>  53560        BKL        1  1101/super.c         c014250d  1130/super.c
>  37742  spin_lock        1   547/sched.c         c0111b04   795/block_dev.c
>  24822  spin_lock        1   678/inode.c         c01551f7   704/inode.c
>  24739  spin_lock        1   291/buffer.c        c014003c   285/buffer.c
>  19330  spin_lock        1   547/sched.c         c0111b04   697/sched.c
>  16566        BKL        1    30/inode.c         c016b971   697/sched.c
>  14049  spin_lock        1  2043/tcp_ipv6.c      e9078837   119/softirq.c
>  11993  spin_lock        1  2111/tcp_ipv4.c      c0220517   119/softirq.c
>  11704        BKL        1   706/block_dev.c     c0144bd7  1381/sched.c
>  11405  spin_lock        1   291/buffer.c        c014003c   280/buffer.c
>  11288        BKL        1   706/block_dev.c     c0144bd7   697/sched.c
>  11213   reacqBKL        9  1375/sched.c         c01138b4   696/block_dev.c
>  11212  spin_lock        1   547/sched.c         c0111b04   696/block_dev.c
>   7552  spin_lock        1   298/buffer.c        c013bb1c   285/buffer.c
>   5013        BKL        0  2763/buffer.c        c013fbca   697/sched.c
>   4641        BKL        1  1302/inode.c         c016de79   697/sched.c
>
> SunWave1#ksymoops -m /boot/System.map -A " c01138b4 c016b971 c0144d51
> c014250d c014250d c0111b04 c01551f7 c014003c c0111b04 c016b971 e9078837
> c0220517 c0144bd7 c014003c c0144bd7 c01138b4 c0111b04 c013bb1c c013fbca
> c016de79"
> ksymoops 2.4.3 on i686 2.4.10-pre12-preempt.  Options used
>      -V (default)
>      -k /proc/ksyms (default)
>      -l /proc/modules (default)
>      -o /lib/modules/2.4.10-pre12-preempt/ (default)
>      -m /boot/System.map (specified)
>
>
> Adhoc c01138b4 <preempt_schedule+34/b0>
> Adhoc c016b970 <reiserfs_delete_inode+30/110>
> Adhoc c0144d50 <blkdev_close+60/1b0>
> Adhoc c014250c <kill_super+ac/280>
> Adhoc c014250c <kill_super+ac/280>
> Adhoc c0111b04 <schedule+34/550>
> Adhoc c01551f6 <prune_icache+36/160>
> Adhoc c014003c <kupdate+11c/210>
> Adhoc c0111b04 <schedule+34/550>
> Adhoc c016b970 <reiserfs_delete_inode+30/110>
> Adhoc e9078836 <[ipv6]tcp6_get_info+4a6/770>
> Adhoc c0220516 <tcp_get_info+4b6/7a0>
> Adhoc c0144bd6 <blkdev_put+46/160>
> Adhoc c014003c <kupdate+11c/210>
> Adhoc c0144bd6 <blkdev_put+46/160>
> Adhoc c01138b4 <preempt_schedule+34/b0>
> Adhoc c0111b04 <schedule+34/550>
> Adhoc c013bb1c <wait_for_locked_buffers+3c/60>
> Adhoc c013fbca <sync_old_buffers+2a/130>
> Adhoc c016de78 <reiserfs_dirty_inode+58/f0>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/