lkml.org 
[lkml]   [2003]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: objrmap and vmtruncate
Andrea Arcangeli <andrea@suse.de> wrote:
>
> On Sat, Apr 05, 2003 at 06:30:03PM +0200, Andrea Arcangeli wrote:
> > On Sat, Apr 05, 2003 at 04:06:14AM -0800, Andrew Morton wrote:
> > > The -aa VM failed in this test.
> > >
> > > __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
> > > VM: killing process rmap-test
> >
> > I'll work on it. Many thanks. I wonder if it could be related to the
> > mixture of the access bit with the overcomplexity of the algorithm that
> > makes the passes over so many vmas useless. Certainly this workload
> > isn't common. I guess what I will try to do first is to simply ignore
> > the accessed bitflag after half of the passes failed. What do you think?

Yes, I agree. If we're getting close to OOM, who cares about accuracy of
page replacement decisions?

> unfortunately I can't reproduce. Booted with mem=256m on a 4-way xeon 2.5ghz:

I only saw it the once. I'd hit ^C on the test and noticed the message on
the console some 5-10 seconds later. It may have been from before the ^C
though. So it _might_ be related to the exit path tearing down pagetables
and setting tons of dirty bits.

> Or maybe it's ext3 related

Conceivably. It wouldn't be the first one. But all the pages were mapped to
disk, so the writepage path is really the same as ext2 in that case.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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