Messages in this thread | | | Date | Tue, 1 Aug 2000 18:06:00 +0200 (CEST) | From | Mike Galbraith <> | Subject | Re: [patch?] Re: Do ramdisk exec's map direct to buffer cache? |
| |
On Tue, 1 Aug 2000, Andrea Arcangeli wrote:
> On Mon, 31 Jul 2000, Linus Torvalds wrote: > > >do something like > > > > int wait; > > > > if (!(gfp_mask & __GFP_IO)) > > goto unlock_continue; > > wait = nr_dirty-- < 0; > > We still want to recycle the clean buffers from a GFP_BUFFER allocation. > The fix I prefer is to pass gfp_mask to try_to_free_buffers and to call > sync_page_buffers only if __GFP_IO was set (checking for it inside > try_to_free_buffers).
Linus's fix seems to do the trick. I beat on it _very hard_ for four hours and couldn't lock it. I'll try your suggestion too. The only thing I saw during pounding is that heavy swapping to a loop device is dog slow.. and maybe a little silly :) but it ran without locking.
Linus: There is something very odd going on though... If I mount -oloop /usr/local and try a make -j30, I see read corruption (cpp carping) as soon as memory pressure hits. If I start with /usr/local mounted, and mount -oremount,loop all is well. (repeatable) When in corruption mode, it will nibble on the underlying fs, so writes are being corrupted too. I've found blocks of zeros replacing various data blocks in the recent past after tinker sessions. (no damage noted today) That's why I agreed with DANGEROUS.. it can nibble an fs pretty badly if you play with it long enough when it's in this.. bad mood.
-Mike
- 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/
| |