<SNIP>
>
> o Patch is reverse :)
> o This can give some nasty deadlocks, better would be to
> allocate one 'last' page to the buffer memory, call
> bdflush, schedule and return. This might give us enough
> delay to clear things up.
> o Something like this, written by me, got rejected by
> Linus once for the very same reason I just outlined :)
>
Astonished by this, because i've had the effect of VERY bad performance
and even locking up WITHOUT my patch.
But with it i never recognized a lockup and allways had sufficient
performance, while doing REALLY i/o intesive tests???
For example fsck'ing large filesystem (20GB++) while doing i/o on
other filesystems.
I'm not sure, why this patch can cause a deadlock, because a "return 0;"
is the "normal" case, if "__get_free_page" in "grow_buffers()" fails.
Heinz
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Systemmanagement Entwicklungsbereich 2 Deutsche Telekom AG Entwicklungszentrum Darmstadt Heinz Mauelshagen Otto-Roehm-Strasse 71c Postfach 10 05 41 mge@ez-darmstadt.telekom.de 64205 Darmstadt Germany +49 6151 886-425 FAX-386 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu