Nick Piggin wrote: > What I found is that, on this system, MADV_FREE performance improvement > was in the noise when you look at it on top of the MADV_DONTNEED glibc > and down_read(mmap_sem) patch in sysbench. I don't want to judge the numbers since I cannot but I want to make an observations: even if in the SMP case MADV_FREE turns out to not be a bigger boost then there is still the UP case to keep in mind where Rik measured a significant speed-up. As long as the SMP case isn't hurt this is reaosn enough to use the patch. With more and more cores on one processor SMP systems are pushed evermore to the high-end side. You'll find many installations which today use SMP will be happy enough with many-core UP machines. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Attachment:
signature.asc
Description: OpenPGP digital signature
- Follow-Ups:
- Re: [PATCH] MM: implement MADV_FREE lazy freeing of anonymous memory
- From: Hugh Dickins <[email protected]>
- Re: [PATCH] MM: implement MADV_FREE lazy freeing of anonymous memory
- From: Nick Piggin <[email protected]>
- Re: [PATCH] MM: implement MADV_FREE lazy freeing of anonymous memory
- References:
- [PATCH] MM: implement MADV_FREE lazy freeing of anonymous memory
- From: Rik van Riel <[email protected]>
- Re: [PATCH] MM: implement MADV_FREE lazy freeing of anonymous memory
- From: Nick Piggin <[email protected]>
- [PATCH] MM: implement MADV_FREE lazy freeing of anonymous memory
- Prev by Date: Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]
- Next by Date: Re: Remove constructor from buffer_head
- Previous by thread: Re: [PATCH] MM: implement MADV_FREE lazy freeing of anonymous memory
- Next by thread: Re: [PATCH] MM: implement MADV_FREE lazy freeing of anonymous memory
- Index(es):
 |