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:	Thu, 12 Apr 2007 07:44:59 +0200
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Rik van Riel <riel@...hat.com>
CC:	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>,
	Ulrich Drepper <drepper@...hat.com>
Subject: Re: [PATCH] make MADV_FREE lazily free memory

Rik van Riel a écrit :
> Eric Dumazet wrote:
>> Rik van Riel a écrit :
>>> Make it possible for applications to have the kernel free memory
>>> lazily.  This reduces a repeated free/malloc cycle from freeing
>>> pages and allocating them, to just marking them freeable.  If the
>>> application wants to reuse them before the kernel needs the memory,
>>> not even a page fault will happen.
> 
>> I dont understand this last sentence. If not even a page fault 
>> happens, how the kernel knows that the page was eventually reused by 
>> the application, and should not be freed in case of memory pressure ?
> 
> Before maybe freeing the page, the kernel checks the referenced
> and dirty bits of the page table entries mapping that page.
> 
>> ptr = mmap(some space);
>> madvise(ptr, length, MADV_FREE);
>> /* kernel may free the pages */
> 
> All this call does is:
> - clear the accessed and dirty bits
> - move the page to the far end of the inactive list,
>   where it will be the first to be reclaimed
> 
>> sleep(10);
>>
>> /* what the application must do know before reusing space ? */
>> memset(ptr, data, 10000);
>> /* kernel should not free ptr[0..10000] now */
> 
> Two things can happen here.
> 
> If this program used the pages before the kernel needed
> them, the program will be reusing its old pages.

ah ok, this is because accessed/dirty bits are set by hardware and not a page 
fault. Is it true for all architectures ?

> 
> If the kernel got there first, you will get page faults
> and the kernel will fill in the memory with new pages.

perfect

> 
> Both of these alternatives are transparent to userspace.
> 

Thanks a lot for these clarifications. This will fly :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ