Subject: Re: [linux-audio-dev] streaming with 2.4.0test11
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Wed Nov 22 2000 - 11:26:59 EET
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--
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ . . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]
This archive was generated by hypermail 2b28 : Wed Nov 22 2000 - 11:30:13 EET