Aye, and it's nice to see that Linux is relatively fast at this.
(See attached table).
Various garbage collectors do this to track dirty pages (clisp, Elk and
Hans Boehm's GC which is now part of the GCC distribution come to mind).
It's a shame this doesn't work for system calls like read(), as they
return EFAULT instead of calling the signal handler. (It could be made
to work with some effort).
-- Jamie
Timing measurements
===================
Here are some rough timings to handle a write protection faults and
change protection from read-only to writable, page by page in
sequential order. 2000 pages were faulted, in a region of
memory-mapped /dev/zero.
The times given are the total running time divided by the number of
pages, so they including the time to call mprotect to unprotect each
page. They are given in microseconds per page, and only the best
observed time is shown. The first column is the time to dirty a zero
page for the first time (the OS must process a second page fault and
COW/allocate a new page in these cases). The second column is the
time to unprotect a page that is already modified, which is the
typical scenario for an incremental garbage collector.
133MHz Pentium Linux 2.3.29 85.52 37.13 (page == 4096).
233MHz dual Pentium II Linux 2.2.17-4 51.17 23.27 (page == 4096).
233MHz Pentium II Linux 2.4.4 51.15 16.60 (page == 4096).
300MHz Pentium II Linux 2.4.4 39.84 13.02 (page == 4096).
366MHz Intel Celeron Linux 2.4.4 38.83 13.02 (page == 4096).
400MHz Pentium II Linux 2.4.2 35.83 12.46 (page == 4096).
600MHz Pentium III Linux 2.4.4 33.60 8.12 (page == 4096).
600MHz Pentium III Linux 2.2.14-5 27.28 7.75 (page == 4096).
600MHz Pentium III Linux 2.2.17-4 28.62 9.36 (page == 4096).
PA-RISC HP-UX (which speed?) 108.44 60.34 (page == 4096).
Sparc Ultra-1 SunOS 5.6 256.69 209.03 (page == 8192).
Sparc SunOS 5.7 machine #1 158.26 102.26 (page == 8192).
Sparc SunOS 5.7 machine #2 190.09 139.25 (page == 8192).
-
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/