Steve Lord wrote:
>
> On Fri, 2002-11-15 at 16:32, Andrew Morton wrote:
> > Zlatko Calusic wrote:
> > >
> > > Oh, yes, you're completely right, of course. It's the pinned part of
> > > page cache that makes big pressure on the memory. Whole lot of
> > > inactive page cache pages (~700MB in my case) is not really good
> > > indicator of recyclable memory, when (probably) a big part of it is
> > > pinned and can't be thrown out. So it is VM, after all.
> >
> > Does xfs_dump actually pin 700 megs of memory??
> >
> > If someone could provide a detailed description of what xfs_dump
> > is actually doing internally, that may help me shed some light.
> > xfs_dump is actually using kernel support for coherency reasons,
> > is that not so? How does it work?
>
> Hmm, a detailed description of xfsdump would take a long time. However,
> it is reading the filesystem via system calls. It uses an ioctl to
> read inodes from disk in chunks, it does not do a directory walk.
> Data is read from files via the read system call. It does keep a
> bunch of stuff around in memory, but this sounds like way too
> much and not at all normal.
Oh, so there isn't any special-purpose in-kernel bulk disk access
stuff to support xfs_dump?
Hm. It should all be easily reclaimable then.
> >
> > Does the machine have highmem?
> >
> > What was the backtrace into the page allocation failure?
>
> and what does the slabcache look like?
Bill Irwin wrote a couple of neat scripts for monitoring slab.
http://www.zipworld.com.au/~akpm/linux/patches/stuff/bloatmeter
http://www.zipworld.com.au/~akpm/linux/patches/stuff/bloatmon
Stick them in your $PATH and run `bloatmeter'.
|