[lkml]   [2000]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.4.0-t9p7 and mmap002 - freeze
On Thu, 28 Sep 2000, Rik van Riel wrote:

> On Thu, 28 Sep 2000, Mike Galbraith wrote:
> > On Wed, 27 Sep 2000, Roger Larsson wrote:
> >
> > > Tried latest patch with the same result - freeze...
> >
> > Ditto.
> I'm finally back from Linux Kongress and Linux Expo and
> will look at the latest tree and integrate the fixes I
> made while on the road later today (after I get some
> sleep).
> I have fixed this particular bug, which was caused by
> us moving unfreeable pages to the inactive_dirty list
> and back again, while not accomplishing anything useful.
> The fix for this is trivial and I'll post it later
> today (cleaned up and working in the current source
> tree).


I've had a tiny bit of success (swptst _passed_ once, and currently
locks with 1 inactive_clean page instead of always 0;) by fiddling
with __alloc_pages() a bit.

One thing that I _think_ may be a problem is using stale information.
direct_reclaim is set once, it's set without checking that a reclaim
is possible, and it's not updated as we proceed although the situation
may change.

Another thing I'm curious about is increasing memory pressure in the
event of an allocation failure (retry). Why do we do that?


-Mike (down periscope.. ahead dead slow;)

P.S. in buffer.c, we do a LockPage(), but no UnlockPage() in the
case of no_buffer_head.. is that correct?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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