Re: [PATCH] reiserfs: kill-the-BKL

[Ingo Molnar <mingo@elte.hu>]

* Andi Kleen <andi@firstfloor.org> 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