On 22 May 2010 14:22, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
> Pedro Ribeiro wrote:
>> Hi all,
>> I was wondering what is the best scheduler for my use case given my
>> current hardware.
>> I have a laptop with a fast Core 2 duo at 2.26 and a nice amount of
>> ram (4GB) which I use primarily for real time audio (though without a
>> -rt kernel). All my partitions are XFS under LVM which itself is
>> contained on a LUKS partition (encrypted with AES 128).
>> CFQ currently does not perform very well and causes a lot of thrashing
>> and high latencies when I/O usage is high. Changing it to the noop
>> scheduler solves some of the problems and makes it more responsive.
>> Still performance is a bit of a let down: it takes 1m30s to unpack the
>> linux-2.6.34 tarball and a massive 2m30s to rm -r.
>> I have lazy-count=1, noatime, logbufs=8, logbsize=256k and a 128m log.
> Are you optimizing for kernel untars, or "real time audio?"
> I would expect that even suboptimal tuning would keep up just fine with
> audio demands.
"real-time audio" is very different from normal audio. In particular,
it requires <10ms response time for jitter free operation. Up to and
including kernel 2.6.33 this was not possible to do reliably without
the -rt patch, no matter how tuned it was.
The big difference came with 2.6.34-rcX and now the stable 2.6.34. It
is now possible to make it work reliable without any audio drops.
But then again, this probably has nothing to do with XFS. My point was
just that while my primary goal is optimum real-time audio, I still
want top reliability (which I could not get with the -rt patch) and
good filesystem performance. Of course the fact that I am using
encryption does not help, but that is another story.
Bottom line, I'm quite happy with XFS and do not plan to change it in
the near future. The only complaint I have is the slow deletion of
large directories like the kernel tree. But I'll trade the reliability
of XFS for that.