[lkml]   [2005]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling wrote:
> On Thu, Jan 20, 2005 at 10:42:24AM -0500, Paul Davis wrote:
>>over on #ardour last week, we saw appalling performance from
>>reiserfs. a 120GB filesystem with 11GB of space failed to be able to
>>deliver enough read/write speed to keep up with a 16 track
>>session. When the filesystem was cleared to provide 36GB of space,
>>things improved. The actual recording takes place using writes of
>>256kB, and no more than a few hundred MB was being written during the
>>failed tests.
> It's been a long while since I followed ReiserFS development closely,
> *however*, this issue used to be a common problem ReiserFS - when
> free space starts to drop below 10%, performace takes a big hit. So
> performance improved when space was cleared up.
> I don't remember what causes this or what the status is in modern
> ResierFS systems.
>>everything i read about reiser suggests it is unsuitable for audio
>>work: it is optimized around the common case of filesystems with many
>>small files. the filesystems where we record audio is typically filled
>>with a relatively small number of very, very large files.
> Anecdotally, I've found this to not be the case. I only use ReiserFS
> and have a few reasonably sized projects in Ardour that work fine:
> maybe 20 tracks, with 10-15 plugins (in the whole project), and I can
> do overdubs with no problems. It may be relevant that I only have a
> four track card and so load is too small.
> But at least in my practice, it hasn't been a huge hinderance.

This is my understanding of the situation, which is not gospel but
interpretation of the information data I have had available.

Reiserfs3.6 is in maintenance mode. Its performance was very good in 2.4
days, but since 2.6 the block layer has matured so much that the code
paths that were fast in reiserfs are no longer so impressive compared to
those shared by ext3.

In terms of recommendation, the latency of non-preemptible codepaths
will be fastest in ext3 in 2.6 due to the nature of it constantly being
examined, addressed and updated. That does not mean it has the fastest
performance by any stretch of the imagination. XFS, I believe, has
significantly faster large file performance, and reiser3.6 has
significantly faster small file performance. But if throughput is not a
problem, and latency is, then ext3 is a better choice. Reiser4 is a
curious beast with obviously high throughput, but for the moment I do
not think it is remotely suitable for low latency applications.

As for the %full issue; no filesystem works well as it approaches full
capacity. Performance degrades dramatically beyond 75% on all of them,
becoming woeful once beyond 85%. If you're looking for good performance,
more free capacity is more effective than changing filesystems.

All of this should be taken into consideration if you're worried about
low latency cpu scheduling, as it all will collapse if your filesystem
code has high latency in the kernel. It also would make benchmarking low
latency cpu scheduling potentially prone to disastrous mis-interpretation.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:09    [W:0.246 / U:0.024 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site