Messages in this thread | | | Date | Mon, 31 Jul 2000 14:16:59 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [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/
| |