Re: 2.4.10-ac10-preempt lmbench output.

[george anzinger <george@mvista.com>]

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/