lkml.org 
[lkml]   [2001]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.4.10-ac10-preempt lmbench output.
Andrew Morton wrote:
>
> 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
> http://www.uow.edu.au/~andrewm/linux/schedlat.html 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).

When running any RT tasks it is aways wise to have an open shell running
at a higher priority. It is also neccessary to have an open console
path to the shell which may mean that X needs to be up there too. But
if this is just a back door, an alternative console could be outside of
X and do the trick.

George

> 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:
> page_cache_get(page);
> spin_unlock(&pagecache_lock);
>
> + 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)) {
> PAGE_BUG(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 <andrea@suse.de> */
>
> #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();
> + }
> spin_lock(&lru_list_lock);
> } while (write_some_buffers(dev));
> run_task_queue(&tq_disk);
> --- 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;
> pte++;
> 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;
> break;
> }
> +
> + 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 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/
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:08    [W:0.090 / U:0.864 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site