Subject: [linux-audio-dev] low-latency patch
From: Andrew Morton (andrewm_AT_uow.edu.au)
Date: Wed Jul 12 2000 - 16:27:17 EEST
This is pretty much "it". I ran it for six hours on a "typical
desktop", running X, netscape, Apache, StarOffice, imapd, ftpd,
sendmail, fetchmail, etc and the worst-case latency was 3-4 millisecs:
0-1 millisecs: 99.999%
1-2 0.0004%
2-3 0.00009%
3-4 0.0005%
Yes, there are probably still ways it can be tripped up, but there's no
point in addressing these unless someone can demonstrate a problem which
doesn't have an acceptable workaround. I can't, apart from waking up
kswapd.
There are now nine rescheduling points which handle:
sys_unlink()
sys_msync()
sys_read()
sys_madvise(MADV_DONTNEED)
sys_write()
sys_sync()
sys_munmap()
sys_exit() (__exit_mm)
It has been given a withering 20-hour stress test on a dual-CPU box.
I'm quite impressed that 2.4 stood up to it, actually.
The patch is quite a bit longer than ten lines because it does some
interface consolidation on zap_page_range().
There may be a buglet in vmtruncate(): the flushes which surround the
second call to zap_page_range() can flush more memory than is being
zapped. However this has been left alone.
It's not clear to this author why some callers to zap_page_range() do
both tlb and cache flushing, but others do just one or neither.
Next time around I'll probably rename conditional_schedule() to
ll_conditional_schedule(), because there are already about 50 instances
of
if (current->need_resched)
schedule();
in the kernel. These should be called conditional_schedule()...
I'll continue to maintain the "Don't do that" list.
Filesystems other than ext2 and NFS client have not been tested.
Patch against 2.4.0-test3 is attached.
This archive was generated by hypermail 2b28 : Wed Jul 12 2000 - 17:07:31 EEST