1 Jun
2011
1 Jun
'11
5:06 p.m.
On Wed, 2011-06-01 at 08:06 -0400, Paul Davis wrote:
On Wed, Jun 1, 2011 at 7:49 AM, Nick Copeland
<nickycopeland(a)hotmail.com> wrote:
This brings up I/O scheduling, which is nowadays just as configurable,
but little discussed 'round these parts... I would think delays that
crazy should definitely be avoidable, particularly in combination with
pre-allocating contiguous disk chunks (fallocate w/ ext4 extents)
Do we (Ardour) have users hitting the limit of their system's disk I/O
abilities? I'd bet that tinkering with this stuff would yield a
considerable improvement...
-dr
I might get flamed for this however GUI should
not really be run with rt
priority,
anyone who would do such a thing is a fool, indeed.
that is an honour for the DSP engines. There are
some reasonable arguments
however for leaning on the scheduler with renice for the user interfaces to
give
them a bit of a bias over other system operations.
what are those arguments? keep in mind that the algorithms inherent in
SCHED_OTHER are targetting console-driven applications that do varying
balances of disk i/o, computation and user input/output. they really
don't address the situation of an app that needs to redraw with a
relatively fixed interval on screen, nor do they provide any actual
scheduling guarantees, which means that any disk i/o issues cannot be
solved with nice - you still have to plan for and deal with the worst
case scenario (which is why ardour's default disk i/o buffers are
*FIVE SECONDS* long (we really have seen delays of this length when
reading from disk!). nice becomes even less relevant in an era of
separate i/o scheduling algorithms that are not designed to pay much
(sometimes no) attention to nice values.