22 Jan
2005
22 Jan
'05
3:45 p.m.
Hi,
i wonder if there's a way to grant a process priority over all other
processes when it comes to disk i/o.. Somewhat similar like SCHED_FIFO
scheduling for cpu priorities.
This would be very useful especially for high reliability hard disk
recording. I mean it would be simply great to record 24 tracks in ardour
and not having to worry about disk underrun [or overrun] when a cronjob
kicks in that scans the whole filesystem..
I heard and read a bit about the new io schedulers in the 2.6.x kernels,
but i wasn't able to find any infos specifically on this subject..
So anyone knows more? Please let us know! Maybe current io-schedulers
actually take the cpu priorities [nice level or relatime priorities]
into account when assigning io bandwidth to processes, but if so i
wouldn't know where to look to find out..
Thanks,
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
22 Jan
22 Jan
4:53 p.m.
On Sat, 2005-01-22 at 21:03 +0100, Florian Schmidt wrote:
Hi,
i wonder if there's a way to grant a process priority over all other
processes when it comes to disk i/o.. Somewhat similar like SCHED_FIFO
scheduling for cpu priorities.
This would be very useful especially for high reliability hard disk
recording. I mean it would be simply great to record 24 tracks in ardour
and not having to worry about disk underrun [or overrun] when a cronjob
kicks in that scans the whole filesystem..
I heard and read a bit about the new io schedulers in the 2.6.x kernels,
but i wasn't able to find any infos specifically on this subject..
So anyone knows more? Please let us know! Maybe current io-schedulers
actually take the cpu priorities [nice level or relatime priorities]
into account when assigning io bandwidth to processes, but if so i
wouldn't know where to look to find out..
http://kerneltrap.org/node/4406
Lee
5:37 p.m.
On Sat, 2005-01-22 at 21:03 +0100, Florian Schmidt
wrote:
> i wonder if there's a way to grant a process priority over all other
> processes when it comes to disk i/o.. Somewhat similar like SCHED_FIFO
> scheduling for cpu priorities.
Lee Revell <rlrevell(a)joe-job.com> writes:
By all means play around with this. But, maintain a healthy
skepticism about it. I seriously doubt any of it is worth worrying
about until after realtime CPU scheduling is rock solid (which is
clearly not the case yet).
--
joq
5:47 p.m.
On Sat, 2005-01-22 at 15:39 -0600, Jack O'Quin wrote:
Exactly, IO works well enough now, we should not encourage people to do
it from an RT thread. If updatedb interferes with your HDR then you are
simply not using a big enough buffer.
Lee
On Sat,
2005-01-22 at 21:03 +0100, Florian Schmidt wrote:
> i wonder if there's a way to grant a process priority over all other
> processes when it comes to disk i/o.. Somewhat similar like SCHED_FIFO
> scheduling for cpu priorities.
Lee Revell <rlrevell(a)joe-job.com> writes:
By all means play around with this. But, maintain a healthy
skepticism about it. I seriously doubt any of it is worth worrying
about until after realtime CPU scheduling is rock solid (which is
clearly not the case yet). 
6:12 p.m.
Exactly, IO works well enough now, we should not
encourage people to do
it from an RT thread. If updatedb interferes with your HDR then you are
simply not using a big enough buffer.
ardour uses an (adjustable) size of 5 seconds per track. if this is
not large enough to smooth out disk scheduling, i don't know what is.
--p
6 p.m.
On Sat, 2005-01-22 at 21:03 +0100, Florian
Schmidt wrote:
> i wonder if there's a way to grant a process priority over all other
> processes when it comes to disk i/o.. Somewhat similar like SCHED_FIFO
> scheduling for cpu priorities.
Lee Revell <rlrevell(a)joe-job.com> writes:
By all means play around with this. But, maintain a healthy
skepticism about it. I seriously doubt any of it is worth worrying
about until after realtime CPU scheduling is rock solid (which is
clearly not the case yet).
6:20 p.m.
On Sat, 22 Jan 2005 17:00:10 -0500
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
>Lee Revell <rlrevell(a)joe-job.com> writes:
>> http://kerneltrap.org/node/4406
>
>By all means play around with this. But, maintain a healthy
>skepticism about it. I seriously doubt any of it is worth worrying
>about until after realtime CPU scheduling is rock solid (which is
>clearly not the case yet).
well, it is pretty much "good enough" for recording with periodsizes
like 1024 frames.
well, given the seriousness of the errors that occur in the case that
florian described, and the absence of xruns in his test cases, there
is an entirely different issue here, one that seems to be totally
disk-centric.
Well, i should describe why i asked this question in the first place. i
played around with multitrack recordings of 16 or 24 tracks, and in
these cases a simple
find /
can cause disk io starvation to ardour. Sure, one could argue: "well,
don't run find /", but i think it would be great to be able to make some
process _always_ get io before any other process.
The io priorities look promising, but they kinda compare to nice values.
Something like SCHED_FIFO for disk io would really be needed to, to
provide really high reliable recording..
flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
8:55 p.m.
Florian Schmidt <mista.tapas(a)gmx.net> writes:
The io priorities look promising, but they kinda
compare to nice values.
Something like SCHED_FIFO for disk io would really be needed to, to
provide really high reliable recording..
IIUC, most file system I/O is actually initiated by a buffer cache
manager in the VM subsystem. At that level, I think it would be quite
difficult to relate a dirty page to properties of the process that had
done the original write().
So, "SCHED_FIFO to disk" might be limited to raw (unbuffered) I/O.
Perhaps that is fine for the scenario you envision.
--
joq
6:40 p.m.
i wonder if there's a way to grant a process
priority over all other
processes when it comes to disk i/o.. Somewhat similar like SCHED_FIFO
scheduling for cpu priorities.
This may be late/redundant/boring, but such is life when you deal with
digests. Jens Axboe's cfq-ts patch fits pretty close to what you
describe, and comes with a utility for setting the io priority. It's
been getting quite a healthy workout by ck mailing list members. I gave
it a good push with Ardour at one point, but then life got in the way.
Jens' last post/patch (that I saw) is at
http://bhhdoa.org.au/pipermail/ck/2005-January/002650.html
It'd be worth skimming the ck archive <http://bhhdoa.org.au/pipermail/ck/>
for hurrahs, horror stories and info on the ionice utility before diving
in though - the earlier warnings on experimentalism are wise counsel.
cheers, Cal
7:10 p.m.
On Sun, 23 Jan 2005 09:40:32 +1100
Cal <hihone(a)bigpond.net.au> wrote:
This may be late/redundant/boring, but such is life
when you deal with
digests. Jens Axboe's cfq-ts patch fits pretty close to what you
describe, and comes with a utility for setting the io priority. It's
been getting quite a healthy workout by ck mailing list members. I gave
it a good push with Ardour at one point, but then life got in the way.
Jens' last post/patch (that I saw) is at
http://bhhdoa.org.au/pipermail/ck/2005-January/002650.html
It'd be worth skimming the ck archive <http://bhhdoa.org.au/pipermail/ck/>
for hurrahs, horror stories and info on the ionice utility before diving
in though - the earlier warnings on experimentalism are wise counsel.
Thanks for the pointers. I will give it a try :)
Btw: i read this mail of yours in the archives:
------
"Hi Con,
This has to be within the realm of dumb questions, and much more likely
to be related to jackd rather than the scheduler, but, if you don't
mind, I'll float it to you and ck at large rather than directly to lkml
(and the bunch of heavy duty groupies your patch has attracted).
When running jack_test4.1 with LD_ASSUME_KERNEL=2.4.19 set, schedtool
shows all the appropriate threads as sched_iso. Without
LD_ASSUME_KERNEL set, there isn't a sched_iso thread to be seen. They
all appear to be sched_normal.
No, no, no ... no suggestion of "It's all your fault!", just thought you
might be able to offer the simple explanation (with minimum embarassment
to moi).
cheers, Cal"
-------
This smells much like the classic nptl-hell some jackd users
experienced. See this page:
http://www.affenbande.org/~tapas/wiki/index.php?Jackd%20and%20NPTL
and tell me what
getconf GNU_LIBPTHREAD_VERSION
reports on your system. The above page also points to a (a little more
detailed) debian bug report. This is imho a glibc issue and not a kernel
issue. But the issue only shows in combination with 2.6.x kernels, since
2.4.x kernels used the linuxthreads system, not nptl..
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
7:54 p.m.
Florian Schmidt wrote:
Thanks for the pointers. I will give it a try :)
Btw: i read this mail of yours in the archives:
------
Indeed it does, so let's not stir it up again unnecessarily!
Lee & joq on jack-devel sorted me out nicely on that one. I normally run
with LD_ASSUME_KERNEL set, but it got overlooked/omitted on one script.
Everthing seemed to be working right, but schedtool didn't show the
class as expected. It seems to be no more than a schedtool quirk when
running with NPTL (accidentally). As guided by joq,
ps -eLo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm
showed things were cool and as expected, even with NPTL.
cheers, Cal
When running jack_test4.1 with
LD_ASSUME_KERNEL=2.4.19 set, schedtool
shows all the appropriate threads as sched_iso. Without
LD_ASSUME_KERNEL set, there isn't a sched_iso thread to be seen. They
all appear to be sched_normal.
-----
This smells much like the classic nptl-hell some jackd users
experienced. See this page:
7188
days inactive
7188
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
5 participants
participants (5)
-
Cal -
Florian Schmidt -
Jack O'Quin -
Lee Revell -
Paul Davis