Andrea Arcangeli <andrea@suse.de> wrote:
>
> CFQ is made for multimedia desktop usage only, you want to be sure
> mplayer or xmms will never skip frames, not for parallel cp reading
> floods of data at max speed like a database with zillon of threads. For
> multimedia not to skip frames 1M/sec is more than enough bandwidth,
> doesn't matter if the huge database in background runs much slower as
> far as you never skip a frame.
These applications are broken. The kernel shouldn't be bending over
backwards trying to fix them up. Because this will never ever work as well
as fixing the applications.
The correct way to design such an application is to use an RT thread to
perform the display/audio device I/O and a non-RT thread to perform the disk
I/O. The disk IO thread keeps the shared 8 megabyte buffer full. The RT
thread mlocks that buffer.
The deadline scheduler will handle that OK. The anticipatory scheduler
(which is also deadline) will handle it better.
If an RT thread performs disk I/O it is bust, and we should not try to fix
it. The only place where VFS/VM/block needs to care for RT tasks is in the
page allocator. Because even well-designed RT tasks need to allocate pages.
The 2.4 page allocator has a tendency to cause 5-10 second stalls for a
single page allocation when the system is under writeout load. That is fixed
in 2.5, but special-casing RT tasks in the allocator would make sense.
-
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/
This archive was generated by hypermail 2b29 : Sun Feb 23 2003 - 22:00:34 EST