Subject: Re: [linux-audio-dev] streaming with 2.4.0test11
From: Roger Larsson (roger.larsson_AT_norran.net)
Date: Wed Nov 22 2000 - 18:20:02 EET
Hi,
There has been some discussion on linux-kernel recently about the
disk elevator algorithms.
The conclusion is that read/writes to data at the end of the disk may
starve... Check out this weeks Linux Weekly News for a
simplified description: http://www.lwn.net
You may use elvtune to tune these settings.
Axboe has also released a test patch that is also said to fix it.
http://www.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0-test11/blk-11.bz2
(not tested by me, I am about to download it)
/RogerL
On Wednesday 22 November 2000 10:26, Kai Vehmanen wrote:
> On Tue, 21 Nov 2000, Paul Barton-Davis wrote:
> >> Now I suspect I'm just running out of disk i/o capacity, although it
> >> seems odd that processes running as normal user without rt-priority can
> >> choke
> >
> > wait kai - are you running the thread that does the disk i/o with
> > SCHED_FIFO ? because if not, surely its not suprising that other
> > disk-ful activities can choke the disk thread, and thus cause the
> > audio thread some problems.
>
> Yes, I'm running all threads with SCHED_FIFO (with audiothread having the
> highest priority). Also, I have a separate test environment, so that the
> added complexity of ecasound's other tasks won't interfere with the
> testing. So it's really plain and simple, two SCHED_FIFO threads running,
> communicating with lock-free operations. Hmm, while browsing through the
> LAD archives, I found these two messages that looked familiar:
>
> First, the following Benno's message: ->
> http://eca.cx/lad/2000/Apr/0160.html
> --cut--
> The problem is when there is a buffer cache flush (kernel disk write
> buffers), then things get realy ugly. even with the disk thread using
> SCHED_FIFO, it doesn't get rescheduled for 4-8 secs SOMETIMES. (since I am
> calling read() and write() ) ARRGH ! Hopefully SCSI disk will make this
> better , but on Windoze you can record painless on EIDE disks, therefore
> the HD recording has to work on Linux on IDE disk as well, or I am forced
> to call it an UNUSABLE OS. :-)
> --cut--
>
> And another interesting post is this Andrew Morton's announce
> of his test9 ll-patches:
> http://eca.cx/lad/2000/Oct/0044.html
> --cut--
> - This entire feature has been *disabled* for SMP. This patch
> is now UP-only.
>
> It is completely stable on SMP and the scheduling latency is
> just grand, as long as you don't push things too hard. It
> then comes unstuck.
>
> This is because of the following scenario:
>
> * CPU1 holds a long-lived spinlock such as dcache_lock
> in select_parent().
>
> * CPU0 is spinning on the same lock.
>
> * An interrupt occurs and the kernel tries to wake up
> your SCHED_FIFO task on CPU0.
>
> You lose. Nothing happens until CPU1 releases the lock
> a week later.
> --cut--
-- -- Home page: http://www.norran.net/nra02596/
This archive was generated by hypermail 2b28 : Wed Nov 22 2000 - 19:14:42 EET