missing madvise functionality



People might remember the thread about mysql not scaling and pointing
the finger quite happily at glibc. Well, the situation is not like that.

The problem is glibc has to work around kernel limitations. If the
malloc implementation detects that a large chunk of previously allocated
memory is now free and unused it wants to return the memory to the
system. What we currently have to do is this:

to free: mmap(PROT_NONE) over the area
to reuse: mprotect(PROT_READ|PROT_WRITE)

Yep, that's expensive, both operations need to get locks preventing
other threads from doing the same.

Some people were quick to suggest that we simply avoid the freeing in
many situations (that's what the patch submitted by Yanmin Zhang
basically does). That's no solution. One of the very good properties
of the current allocator is that it does not use much memory.

A solution for this problem is a madvise() operation with the following
property:

- the content of the address range can be discarded

- if an access to a page in the range happens in the future it must
succeed. The old page content can be provided or a new, empty page
can be provided

That's it. The current MADV_DONTNEED doesn't cut it because it zaps the
pages, causing *all* future reuses to create page faults. This is what
I guess happens in the mysql test case where the pages where unused and
freed but then almost immediately reused. The page faults erased all
the benefits of using one mprotect() call vs a pair of mmap()/mprotect()
calls.

So, if all those who were so interested in that micro benchmark could
now please direct their attention to a good madvise solution I'd be much
obliged. It'll be put to good use right away and it should be quite
easy to provide a glibc patch to test the new kernel code.

--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

Attachment: signature.asc
Description: OpenPGP digital signature



Relevant Pages

  • Re: database application (with GUI interface)?
    ... >>MySQL.com has one for MySQL, there is a third party interface fro MySQL too ... Mandrake does supply mysql and you have an RPM somewhere on your Mandrake CDs, ... select the one that matches your glibc (it's ... As the version from mysql.com is a tarball, you have to run an install file, ...
    (alt.os.linux)
  • Re: deb src
    ... assembly gcc 4.0.1, glibc 2.3.5, MySQL 5.0.12? ... There Is such resource ... where are storedall diff.gz for all versions of source codes? ...
    (Debian-User)
  • Re: malloc and Active memory
    ... > The mallocfunction is entirely userspace code, part of glibc. ... > is mostly imune to many forms of traditional memory fragmentation. ... - Heuristic overcommit handling. ... CommitLimit: 8646184 kB ...
    (Fedora)
  • Re: missing madvise functionality
    ... The problem is glibc has to work around kernel limitations. ... memory is now free and unused it wants to return the memory to the ... causing *all* future reuses to create page faults. ...
    (Linux-Kernel)
  • Re: missing madvise functionality
    ... The problem is glibc has to work around kernel limitations. ... memory is now free and unused it wants to return the memory to the ... causing *all* future reuses to create page faults. ...
    (Linux-Kernel)