linux-kernel - [PATCH] stub MADV

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 07 May 2007 23:51:47 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Nick Piggin <nickpiggin@...oo.com.au>
CC:	Ulrich Drepper <drepper@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jakub Jelinek <jakub@...hat.com>, Dave Jones <davej@...hat.com>
Subject: [PATCH] stub MADV_FREE implementation

Until we have better performance numbers on the lazy reclaim path,
we can just alias MADV_FREE to MADV_DONTNEED with this trivial
patch.

This way glibc can go ahead with the optimization on their side
and we can figure out the kernel side later.

Signed-off-by: Rik van Riel <riel@...hat.com>

---
When I get back from the Red Hat Summit (Saturday), I will run more
performance numbers with and without the lazy reclaiming of pages.

Nick Piggin wrote:
> Ulrich Drepper wrote:
>> 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.
> 
> OK, sure. I think we need more numbers though.
> 
> And even if this was a patch with _no_ possibility for regressions and it
> was a completely trivial one that improves performance in some cases...
> one big problem is that it uses another page flag.
> 
> I literally have about 4 or 5 new page flags I'd like to add today :) I
> can't of course, because we have very few spare ones left.
> 
>  From the MySQL numbers on this system, it seems like performance is in the
> noise, and MADV_DONTNEED makes the _vast_ majority of the improvement.
> This is also the case with Rik's benchmarks, and while he did see some
> improvement, I found the runs to be quite variable, so it would be ideal
> to get a larger sample.
> 
> And the fact that the poor behaviour of the old style malloc/free went
> unnoticed for so long indicates that it won't be the end of the world if
> we didn't merge MADV_FREE right now.
> 


-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.

View attachment "stub-madv_free" of type "text/plain" (4878 bytes)