[LAD] Any package builders here?

[David Robillard]

On Wed, 2011-06-01 at 08:06 -0400, Paul Davis wrote:
> On Wed, Jun 1, 2011 at 7:49 AM, Nick Copeland <nickycopeland at hotmail.com> wrote:
> > 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.

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