From: Rik van Riel <riel@redhat.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Eric Dumazet <dada1@cosmosbay.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
Ulrich Drepper <drepper@redhat.com>
Subject: Re: [PATCH] make MADV_FREE lazily free memory
Date: Thu, 12 Apr 2007 03:22:44 -0400 [thread overview]
Message-ID: <461DDE44.2040409@redhat.com> (raw)
In-Reply-To: <461DCDDA.2030502@yahoo.com.au>
Nick Piggin wrote:
> Nick Piggin wrote:
>> Eric Dumazet wrote:
>>
>
>>>> 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.
>>
>>
>> No it isn't.
>
> That is to say, it isn't required for correctness. But if the
> question was about avoiding a fault, then yes ;)
Making the pte clean also needs to clear the hardware writable
bit on architectures where we do pte dirtying in software.
If we don't, we would have corruption problems all over the VM,
for example in the code around pte_clean_one :)
> But as Linus recently said, even hardware handled faults still
> take expensive microarchitectural traps.
Nowhere near as expensive as a full page fault, though...
The lazy freeing is aimed at avoiding page faults on memory
that is freed and later realloced, which is quite a common
thing in many workloads.
--
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.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-04-12 7:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-11 4:30 Rik van Riel
2007-04-11 22:41 ` Eric Dumazet
2007-04-11 22:56 ` Rik van Riel
2007-04-12 5:44 ` Eric Dumazet
2007-04-12 6:08 ` Nick Piggin
2007-04-12 6:12 ` Nick Piggin
2007-04-12 7:22 ` Rik van Riel [this message]
2007-04-12 13:14 ` Nick Piggin
2007-04-12 20:58 ` Rik van Riel
2007-04-13 0:34 ` Nick Piggin
2007-04-16 16:10 ` Anton Blanchard
2007-04-16 16:30 ` Jakub Jelinek
2007-04-16 18:39 ` Anton Blanchard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=461DDE44.2040409@redhat.com \
--to=riel@redhat.com \
--cc=dada1@cosmosbay.com \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox