This is the mail archive of the
mailing list for the glibc project.
Re: improving malloc
>> I'm one of kernel memory folks and I'd like to explain how mvolatile() does.
>> It give a hint that given ranges are discardable to kernel. Thus when getting
>> memory pressure, kernel just drop such memory instead of swap out. It help
>> to minimalize wrong returning memory cost.
>> see https://lwn.net/Articles/531305/
> When these pages are result of fragmentation caused by large malloc it
> is wasteful to swap them.
Current approach (using madvise(MADV_DONTNEED)) also can avoid swapping out.
So, mvolatile don't make any difference from point of swapping view.
> A possible alternative could be implement most of this in userspace by
> callback that tells which pages can be zeroed.
No comments. As you know, userspace implementation makes a lot of
race in general. I'm not sure it can practical performance improvement,
however, i can not comment it until i see actual code.
>> btw, I don't understand Ondrej's "linked list" is which mechanism
>> point to. Can anyone clarify?
> One can allocate >10 page requests with nearly zero fragmentation
> (on 64-bit systems where address exhaustion is not problem.) and
> quite slowly with calling mmap/munmap instead of malloc/free.
> Zeroing memory on that mmap(with some new flag) could be avoided
> by kernel tracking and reusing unmaped memory.
So, I don't disagree kernel can implement per-process unmapped memory
cache. however I don't see any advantage because 1) it also need take
mmap_sem and then it may be slower than madvise(DONTNEED) and
2) As you know, using M_TRIM_THRESHOLD=-1 can avoid zeroing memory
completely. It is most efficient rather than any kernel mechanism.
Maybe I'm overlooking anything. When posting actual code, probably I can talk
about more productive comment.