On Wed, 2011-06-01 at 08:06 -0400, Paul Davis wrote: > On Wed, Jun 1, 2011 at 7:49 AM, Nick Copeland <[email protected]> > 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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
