* Andi Kleen <andi@xxxxxxxxxxxxxx> wrote: > > Using a mutex seems like the sane choice here. I'd advocate spinlocks > > for a new filesystem any day (but even there it's a fine choice to have > > a mutex, if top of the line scalability is not an issue). > > > > But for a legacy filesystem like reiser3, which depended on the BKL > > reiser3 is much more widely used in the user base than a lot of > "non legacy" file systems. It's very likely it has significantly > more users than ext4 for example. Remember that it was the default > file system for a major distribution until very recently. [...] ( Drop the condescending tone please - i very much know that SuSE installed reiser3 by default for years. It is still a legacy filesystem and no new development has gone into it for years. ) > [...] I also got a few reiser3 fs still around, it tended to > perform very well on kernel hacker workloads. Then i am sure you must like this patch: it introduces a per superblock lock, splitting up the big BKL serialization. You totally failed to even acknowledge that advantage, maybe you missed that aspect? For example, if you have /home and / on separate reiser3 filesystems, you could see as much as a 200% jump in performance straight away on certain workloads, on a dual-core box. That big BKL overhead is a real reiser3 scalability problem - especially on reiser3 using servers which are likely to have several filesystems on the same box. Frederic reported a slight drop in single-threaded performance, to be expected from a work in progress patch. Ingo -- To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
