Re: bigcore.exp on 64-bit systems

[Daniel Jacobowitz <drow at false dot org>]

On Sat, Jan 13, 2007 at 07:31:35PM +0100, Ulrich Weigand wrote:
> Mark Kettenis wrote:
> 
> > 2.6.16 certainly qualifies as modern.  The idea is that the test will
> > create a sparse core file, that will take up almost no disk space.
> > But the fact that it takes more than 600 seconds to dump the core file
> > (that's the cause of the SIGABRT timeout), suggests that it isn't
> > doing that.
> 
> The problem I've seen on certain Linux kernel versions is that while
> generating the core file, the kernel fully populates the page tables
> spanning the (zero) heap allocated by the bigcore test.
> 
> This means that while it doesn't allocate memory (or disk space) for
> the heap itself, it will allocate non-pageable memory for the page
> tables, and if the heap gets to several TB, that means several GB
> of page tables.

Hmm... very interesting.  I see that when I run it, it works itself up
to almost 1GB resident memory usage.  If you don't happen to have that
much free memory available without swapping other stuff out, then I'd
believe that the test could take longer than the timeout.  Fencepost
has enough RAM, but only barely, and is running plenty of other things.

The test was originally written for >2GB corefiles on 32-bit systems,
specifically to test signed / unsigned file offset bugs.  Testing that
on 64-bit systems would need a > 8EB (exabyte) core file.  That just
Doesn't Happen on today's systems; my 64-bit Linux system manages
to allocate "only" 1TB of RAM.

Ergo I don't think what it's doing right now is useful.  Should we
limit its allocation to, perhaps, 4GB (2**32)?

For comparison purposes, an 8GB limit on my system completes the core
dump in 1.6 seconds.  No limit yields a 1TB dump, and takes 97 seconds. 
I'd be happy to have that time back :-)

-- 
Daniel Jacobowitz
CodeSourcery