Re: missing madvise functionality

Ulrich Drepper wrote:
Nick Piggin wrote:

Cool. According to my thinking, madvise(MADV_DONTNEED) even in today's
kernels using down_write(mmap_sem) for MADV_DONTNEED is better than
mmap/mprotect, which have more fundamental locking requirements, more
overhead and no benefits (except debugging, I suppose).


It's a tiny bit faster, see

http://people.redhat.com/drepper/dontneed.png

I just ran it once so the graph is not smooth. This is on a UP dual
core machine. Maybe tomorrow I'll turn on the big 4p machine.

Hmm, I saw an improvement, but that was just on a raw syscall test
with a single page chunk. Real-world use I guess will get progressively
less dramatic as other overheads start being introduced.

Multi-thread performance probably won't get a whole lot better (it does
eliminate 1 down_write(mmap_sem), but one remains) until you use my
madvise patch.


I would have to see dramatically different results on the big machine to
make me change the libc code. The reason is that there is a big drawback.

So far, when we allocate a new arena, we allocate address space with
PROT_NONE and only when we need memory the protection is changed to
PROT_READ|PROT_WRITE. This is the advantage of catching wild pointer
accesses.

Sure, yes. And I guess you'd always want to keep that options around as
a debugging aid.

--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: missing madvise functionality
    ... mmap/mprotect, which have more fundamental locking requirements, more ... overhead and no benefits (except debugging, ... So far, when we allocate a new arena, we allocate address space with ...
    (Linux-Kernel)
  • Re: Recursive subroutine for reading null-terminated string
    ... and any other call overhead. ... I thought that normal arrays are allocated a single ... and just before the ALLOCATE. ... for recursion up to that point. ...
    (comp.lang.fortran)
  • Re: page sizes
    ... The documentation of malloc() on one of the ... Larger blocks allocate fastest if they are ... overhead by always putting chunks on cacheline boundaries (and wasting ...
    (comp.programming)
  • Re[2]: [PATCH][v2] fork_init: fix division by zero
    ... overhead before this patch: e.g. your implementation is finally boils ... common situation of small PAGE_SIZEs. ... can't allocate thread structs from highmem. ... Emcraft Systems, www.emcraft.com ...
    (Linux-Kernel)
  • Re: State of Forth 200x
    ... run-time overhead ... It's just ALLOCATE and MOVE to copy a small memory region, ... dumb old W32F) in using them. ... IMO objects that are definitely needed ...
    (comp.lang.forth)