lkml.org 
[lkml]   [2000]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch?] Re: Do ramdisk exec's map direct to buffer cache?


On Sun, 30 Jul 2000, Mike Galbraith wrote:
>
> I keep running into a deadlock with it looping forever trying to
> free memory, triggered by blocking in getblk->refill_freelist->..
> try_to_free_buffers->sync_page_buffers->zzzzz (kflushd runs forever).

Hmm.. I just noticed something. The above really shouldn't happen in the
first place.

The "refill_freelist()" function allocates memory with GFP_BUFFER, which
should not allow the above kind of "try_to_free_buffers()" behavior.

As far as I can tell, we should really honour the fact that GFP_IO isn't
set, and we mustn't do any IO.

So maybe the loopback device problem is actually due to a real bug
independent of the loopback device.

Mike, would you mind checking something where mm/filemap.c does _not_ do
the "try_to_free_buffers()" when GFP_IO isn't set? Instead of

int wait = ((gfp_mask & __GFP_IO) && (nr_dirty-- < 0));

do something like

int wait;

if (!(gfp_mask & __GFP_IO))
goto unlock_continue;
wait = nr_dirty-- < 0;

or similar. Does that make loopback happier?

Linus


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

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