On Tue, 2004-07-20 at 08:19, Jens Axboe wrote:> On Tue, Jul 20 2004, Ingo Molnar wrote:> > > How much I/O do you allow to be in flight at once? It seems like by> > > decreasing the maximum size of I/O that you handle in one interrupt> > > you could improve this quite a bit. Disk throughput is good enough,> > > anyone in the real world who would feel a 10% hit would just throw> > > hardware at the problem.> > > > i'm not sure whether this particular value (max # of sg-entries per IO> > op) is runtime tunable. Jens? Might make sense to enable elvtune-alike> > tunability of this value.> > elvtune is long dead :-)> > it's not tweakable right now, but if you wish to experiment you just> need to add a line to ide-disk.c:idedisk_setup() - pseudo patch:> > + blk_queue_max_sectors(drive->queue, 32);> +> printk("%s: max request size: %dKiB\n", drive->name, drive->queue->max_sectors / 2);> > /* Extract geometry if we did not already have one for the drive */> > above will limit max request to 16kb, experiment as you see fit.

I will give this a try.

Using 2.6.8-rc1-mm1, with La Monte H. P. Yarroll's patch to daemonizesoftirqs, running two jackds (one in the playback direction, one incapture, to work around an issue with the emu10k1 driver) with 2 periodsof 32 frames (666 usec), I am no longer seeing any XRUNS at all once thejackd processes are up and running. I tried stressing the filesystem byrecompiling ALSA while running a 'du /' and a 'find / -ls'. Thescheduling jitter peaks occasionally at around 100000 CPU cycles (166usecs) every few seconds, but this is as high as it goes.This is as good or better than a 2.4 kernel with the low latencypatches.

I do not have voluntary preemption enabled, as I do not have a versionof the patch that corresponds to this kernel.

The only XRUNS I still get seem related to ioctl() and mlockall(). These both cause an XRUN in one jackd process when starting another: