This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

external/1551: Kernel does not support sparse core files


>Number:         1551
>Category:       external
>Synopsis:       Kernel does not support sparse core files
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 12 17:48:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     ac131313@redhat.com
>Release:        unknown-1.0
>Organization:
>Environment:

>Description:
A kernel, when creating a core file, can minimize the amount of data written to disk by not writing zero and/or unmapped pages.  Instead, by seeking over such "holes", and exploiting its support for sparse files (where there are unallocated holes that read as zero) the Kernel can avoid much of the disk traffic.

For instance, the program gdb.base/bigcore.c, which allocates but does not access most of its memory, a significant performance gan (both in disk usage and time to write the file) can be had:

$ time ./bigcore
...
Segmentation fault (core dumped)
real    0m1.107s
user    0m0.010s
sys     0m1.030s
$ ls -l core.25490 
-rw-------  1 cagney cagney 1993760768 Feb 12 12:33 core.25490
$ du -sk core.25490 
280     core.25490

That's 1.9Gig vs 0.3Meg.

As a consequence, the test gdb.base/bigcore.exp is being disabled (marked as untested) on systems that do not support sparce core files.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]