lkml.org 
[lkml]   [1998]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Buffer Memory
On Thu, 11 Jun 1998, Heinz Mauelshagen wrote:
> On Thu, 11 Jun 1998, Rik van Riel wrote
>
> > 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.
>
> Astonished by this, because i've had the effect of VERY bad performance
> and even locking up WITHOUT my patch.

That's the same here, when I implemented my version
of the patch. But apperantly there are some places
in the kernel which could lock when there are no
buffers (Linus?). At least, that's the answer I got
when Linus rejected my patch.

And since I've got a feeling that he might be right,
it would be best to just allocate one page at a time,
wake up kflushd and schedule when we hit this situation.

> 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.

It could cause a deadlock when we need a buffer in order
to do something semi-critical inside of the kernel. At
least, according to Linus. Maybe Stephen Tweedie has more
info, or knows something to disprove Linus' point of view.
It would be nice if we could be sure that your code worked
correctly...

Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.032 / U:0.912 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site