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

[Ingo Molnar]

* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> > Better would be to use spinlocks if possible. I guess you just would 
> > need to find all sleep points and wrap them with lock dropping?
> 
> I do agree that a filesystem should try to avoid sleeping locks if at 
> all possible, especially on the paths that the VM uses for writeback. 
> But on the other hand, I think the issue with reiserfs is just the bad 
> latencies that the BKL can cause, and then it doesn't matter.

The main motivator is the tip:core/kill-the-BKL tree: we are working on 
removing the BKL from all of the kernel, once and forever. We are 
actually quite close to that end goal: reiser3 was the last big 
stumbling block and it's great that Frederic is tackling that.

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 
auto-dropping on schedule() it would be rather fragile to use spinlocks, 
and it would take forever to validate the result. Just one codepath 
missed with having some rare scheduling possibility and we'd have a 
kernel crash down the road.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/