[linux-audio-dev] Re: [DATAPOINT] kernels and latencies

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] Re: [DATAPOINT] kernels and latencies
From: Andrew Morton (andrewm_AT_uow.edu.au)
Date: Mon Jul 03 2000 - 21:22:54 EEST

Roger Larsson wrote:
>
> Hi,
>
> I have gone trough my collected data and found that
> the best yet (non latency patched) is
> test1-ac22-riel++
> It works perfectly for streaming read/write/copy
> (latencies to SCHED_FIFO process below 5 ms !)
> but fails for mmap002 with latencies > 180 ms

With a conditional reschedule in generic_file_read,
generic_file_write and truncate_inode_pages the scheduling
latency falls from 130 millisecs to 4 millisecs during a kernel build.

I don't think mmap002 is a very pointful test. "Don't
run mmap002 when you're doing multimedia".

Here's the story on mmap002:

switchin_0144:0 -> switchout_0144:0 2600 .90 159336.00 319.49 830693.16
   start_0144:0 -> switchout_0144:0 2 2552.31 100519.87 51536.09 103072.18
           open.c:811 -> open.c:813 78 .15 74553.96 960.08 74886.74
switchin_0120:0 -> switchout_0120:0 2418 .65 58210.29 451.25 1091147.90
      switchin_0001:0 -> open.c:806 1 50005.77 50005.77 50005.77 50005.77
   start_0001:0 -> switchout_0001:0 1 14107.08 14107.08 14107.08 14107.08
switchin_0001:0 -> switchout_0001:0 54 263.45 3880.48 1696.84 91629.60
     switchin_0106:0 -> stop_0106:0 4 3.50 1420.02 419.48 1677.94
         start_0011:0 -> open.c:834 3 220.58 719.98 487.38 1462.15

                                                       ^^^^^^^^^
                                                      This column

160 milliseconds in sys_msync() -> "don't use sys_msync()...."

That 75 millisecs in open.c is the fput(filp) in sys_close(). Investigating...

syscall 120 is sys_clone.

syscall 1 is sys_exit.

All very interesting, but really the only thing which needs tweaking in
the filesystem apart from the patch below appears to be sys_close(). After that
I'll take a look at X11 and /proc performance.

On a fast uniprocessor, it is going to be very hard to do better
than 3.5 milliseconds.

BTW: I love the comment below about shared mappings :)

Index: mm/filemap.c
===================================================================
RCS file: /opt/cvs/lk/mm/filemap.c,v
retrieving revision 1.16.2.7
diff -u -r1.16.2.7 filemap.c
--- mm/filemap.c 2000/06/30 08:26:00 1.16.2.7
+++ mm/filemap.c 2000/07/03 18:12:35
@@ -29,6 +29,8 @@
 
 #include <linux/highmem.h>
 
+#include <asm/timepeg.h>
+
 /*
  * Shared mappings implemented 30.11.1994. It's not fully working yet,
  * though.
@@ -160,6 +162,8 @@
         start = (lstart + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
 
 repeat:
+ if (current->need_resched)
+ schedule(); // AKPM
         head = &mapping->pages;
         spin_lock(&pagecache_lock);
         curr = head->next;
@@ -1043,6 +1047,9 @@
                 struct page *page, **hash;
                 unsigned long end_index, nr;
 
+ if (current->need_resched) // AKPM3
+ schedule();
+
                 end_index = inode->i_size >> PAGE_CACHE_SHIFT;
                 if (index > end_index)
                         break;
@@ -2490,6 +2497,9 @@
         while (count) {
                 unsigned long bytes, index, offset;
                 char *kaddr;
+
+ if (current->need_resched)
+ schedule();
 
                 /*
                  * Try to find the page in the cache. If it isn't there,

New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Jul 03 2000 - 21:40:35 EEST