Re: vm kills processes in our 2.3.12 port of reiserfs - what

Hans Reiser (reiser@idiom.com)
Tue, 31 Aug 1999 21:28:23 +0400


Andrea Arcangeli wrote:

> On Mon, 30 Aug 1999, Hans Reiser wrote:
>
> >I agree whole heartedly with this sentiment that atomic
> >mark_buffer_dirty() should be available. My question is: shouldn't the sleeping
>
> Minor correction: atomic is not the right adjective IMHO.
> mark_buffer_dirty() should only do some more work to be backwards
> compatible.
>
> Andrea

Yes, you are right, atomic is the wrong term, I meant "schedule-free".

We can do it as Linus asks, I think that for me the main thing is that I'd like to
encourage you guys
to let us know when you change things like this. Adding schedule to
mark_buffer_dirty() broke our code,
and then removing the stalling confused us more. End of whine.:-)

Reiserfs currently breaks big time in certain places if mark_buffer_dirty() is not
schedule-free. You can correctly say that if
we did a proper job of fine-grained locking we would not have this problem, but
several years ago I couldn't get
a certain programmer no longer with Namesys to read the textbook treatments of
locking that I sent him and told him to read,
nor to trust me that they were the right way to do it, and he decided to do it the
schedule avoiding way that the rest of the linux kernel does (err, did), and so here
I am.

The guy who will fine-grain locks in reiserfs started today. When he is done we
will not need to worry about whether mark_buffer_dirty () causes schedule. Thanks
to Linus for telling us about this new method we are expected to use
until reiserfs is fine grained locked.

Hans

--
Get Linux (http://www.kernel.org) plus ReiserFS
 (http://devlinux.org/namesys).  If you sell an OS or
internet appliance, buy a port of ReiserFS!  If you
need customizations and industrial grade support, we sell them.

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