Re: 2.4.10-ac10-preempt lmbench output.

From: Andrew Morton (
Date: Wed Oct 10 2001 - 00:13:58 EST

Dieter Nützel wrote:
> Andrew have you a current version of your lowlatency patches handy?

mm.. Nice people keep sending me updates. It's at and applies
to 2.4.11 with one little reject. I don't know how it's
performing at present - it's time for another round of tuning
and testing.

wrt this discussion: I would assume that xmms is simply stalling
on disk access. All it takes is for one of its text pages to be
dropped and it could have to wait a very long time indeed to
come back to life. The disk read latency could easily exceed
any sane buffering in the sound card or its driver.

The application should be using mlockall(MCL_FUTURE) and it should
run `nice -19' (SCHED_FIFO and SCHED_RR are rather risky - if the
app gets stuck in a loop, it's time to hit the big button). If the
app isn't doing both these things then it just doesn't have a chance.

I don't understand why Andrea is pointing at write throttling? xmms
doesn't do any disk writes, does it??

Andrea's VM has a rescheduling point in shrink_cache(), which is the
analogue of the other VM's page_launder(). This rescheduling point
is *absolutely critial*, because it opens up what is probably the
longest-held spinlock in the kernel (under common use). If there
were a similar reschedulig point in page_launder(), comparisons
would be more valid...

I would imagine that for a (very) soft requirement such as audio
playback, the below patch, combined with mlockall and renicing
should fix the problems. I would expect that this patch will
give effects which are similar to the preempt patch. This is because
most of the other latency problems are under locks - icache/dcache
shrinking and zap_page_range(), etc.

This patch should go into the stock 2.4 kernel.

Oh. And always remember to `renice -19' your X server.

--- linux-2.4.11/mm/filemap.c Tue Oct 9 21:31:40 2001
+++ linux-akpm/mm/filemap.c Tue Oct 9 21:47:51 2001
@@ -1230,6 +1230,9 @@ found_page:
+ if (current->need_resched)
+ schedule();
                 if (!Page_Uptodate(page))
                         goto page_not_up_to_date;
                 generic_file_readahead(reada_ok, filp, inode, page);
@@ -2725,6 +2728,9 @@ generic_file_write(struct file *file,con
                 if (!PageLocked(page)) {
+ if (current->need_resched)
+ schedule();
                 kaddr = kmap(page);
                 status = mapping->a_ops->prepare_write(file, page, offset, offset+bytes);
--- linux-2.4.11/fs/buffer.c Tue Oct 9 21:31:40 2001
+++ linux-akpm/fs/buffer.c Tue Oct 9 22:08:51 2001
@@ -29,6 +29,7 @@
 /* async buffer flushing, 1999 Andrea Arcangeli <> */
 #include <linux/config.h>
+#include <linux/compiler.h>
 #include <linux/sched.h>
 #include <linux/fs.h>
 #include <linux/slab.h>
@@ -231,6 +232,10 @@ static int write_some_buffers(kdev_t dev
 static void write_unlocked_buffers(kdev_t dev)
         do {
+ if (unlikely(current->need_resched)) {
+ __set_current_state(TASK_RUNNING);
+ schedule();
+ }
         } while (write_some_buffers(dev));
--- linux-2.4.11/fs/proc/array.c Sun Sep 23 12:48:44 2001
+++ linux-akpm/fs/proc/array.c Tue Oct 9 21:47:51 2001
@@ -414,6 +414,9 @@ static inline void statm_pte_range(pmd_t
                 pte_t page = *pte;
                 struct page *ptpage;
+ if (current->need_resched)
+ schedule(); /* For `top' and `ps' */
                 address += PAGE_SIZE;
                 if (pte_none(page))
--- linux-2.4.11/fs/proc/generic.c Sun Sep 23 12:48:44 2001
+++ linux-akpm/fs/proc/generic.c Tue Oct 9 21:47:51 2001
@@ -98,6 +98,9 @@ proc_file_read(struct file * file, char
                                 retval = n;
+ if (current->need_resched)
+ schedule(); /* Some proc files are large */
                 /* This is a hack to allow mangling of file pos independent
                   * of actual bytes read. Simply place the data at page,
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Oct 15 2001 - 21:00:29 EST