On Mon, Aug 04, 2003 at 01:10:56PM -0500, Steve Lord wrote:
> On Sat, 2003-08-02 at 03:30, Andrew Morton wrote:
> > Using Linus's current tree plus all the -mm gunk I get a fairly easy oops
> > running dbench on XFS on SMP with CONFIG_DEBUG_PAGEALLOC=y:
>
> I can't hit it for some reason, but yes, I see it. As for why xfs
I'm also unable to hit it - do you have anything special to generate
that signal to kgdb Andrew? I'm using a hacked up kdb, not kgdb, but
would have expected the pagealloc debug stuff still to trip me up on
a bad pointer dereference. Any particular number of dbench clients?
(thanks - I just want to be able to verify the fix, so want to start
from a failing state).
> and dbench don't mix so well - its a 2.6 thing, but having looked
> at what the other places which wait for I/O in the kernel do, perhaps
> if we made some similar changes to the xfs specific spots, things might
> improve. Looks like getting into io_schedule would be a good thing
> in a few strategic places.
From some simple dbench tests we seem to be getting about half the
throughput in 2.6 that we get in 2.4.
> > Program received signal SIGEMT, Emulation trap.
> > 0xc0282c9d in xfs_iflush (ip=0xc284a004, flags=2) at
> > fs/xfs/pagebuf/page_buf.h:397
> > 397 if (!pb || atomic_read(&pb->pb_io_remaining))
> > (gdb) p pb
> > $1 = (page_buf_t *) 0xc98d1004
> > (gdb) p *pb
> > Cannot access memory at address 0xc98d1004
> > (gdb) bt
> > #0 0xc0282c9d in xfs_iflush (ip=0xc284a004, flags=2) at
> > fs/xfs/pagebuf/page_buf.h:397
> > ...
> >
> > The memory at 0xc98d1004 has been unmapped.
> > ...
> >
> > The below quick patch fixes it up. But it also causes zillions of dentries
> > and inodes to be leaked for some reason. Consider it a technology
> > demonstration!
Using a slight variation on your patch, same idea though, I am
not seeing a dentry/inode leak (I'm looking at /proc/slabinfo,
or is there some other definitive source?) and also not seeing
any problems with debug_pagealloc switched on (but then, I was
unable to hit it beforehand either).
thanks.
--
Nathan
|