linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Miaohe Lin <linmiaohe@huawei.com>
To: Peter Xu <peterx@redhat.com>
Cc: <akpm@linux-foundation.org>, <willy@infradead.org>,
	<vbabka@suse.cz>, <dhowells@redhat.com>, <neilb@suse.de>,
	<david@redhat.com>, <apopple@nvidia.com>, <surenb@google.com>,
	<minchan@kernel.org>, <sfr@canb.auug.org.au>,
	<naoya.horiguchi@nec.com>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/3] mm/madvise: free hwpoison and swapin error entry in madvise_free_pte_range
Date: Fri, 22 Apr 2022 10:47:32 +0800	[thread overview]
Message-ID: <d391b905-e017-5d0c-7485-2ea51d2587ae@huawei.com> (raw)
In-Reply-To: <YmFqHBMtNKqib8lt@xz-m1.local>

On 2022/4/21 22:28, Peter Xu wrote:
> On Thu, Apr 21, 2022 at 08:53:48PM +0800, Miaohe Lin wrote:
>> Once the MADV_FREE operation has succeeded, callers can expect they might
>> get zero-fill pages if accessing the memory again. Therefore it should be
>> safe to delete the hwpoison entry and swapin error entry. There is no
>> reason to kill the process if it has called MADV_FREE on the range.
>>
>> Suggested-by: Alistair Popple <apopple@nvidia.com>
>> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
>> ---
>>  mm/madvise.c | 13 ++++++++-----
>>  1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/mm/madvise.c b/mm/madvise.c
>> index 4d6592488b51..5f4537511532 100644
>> --- a/mm/madvise.c
>> +++ b/mm/madvise.c
>> @@ -624,11 +624,14 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
>>  			swp_entry_t entry;
>>  
>>  			entry = pte_to_swp_entry(ptent);
>> -			if (non_swap_entry(entry))
>> -				continue;
>> -			nr_swap--;
>> -			free_swap_and_cache(entry);
>> -			pte_clear_not_present_full(mm, addr, pte, tlb->fullmm);
> 
> Nitpick: IMHO you don't need to invert non_swap_entry() then it'll generate
> a smaller diff, just add the new code above "continue".

I tried this way, but that lead to long line splitting, so I rewrote the code like this.
If you prefer to just add the new code above "continue", I will do it in the next version.

> 
>> +			if (!non_swap_entry(entry)) {
>> +				nr_swap--;
>> +				free_swap_and_cache(entry);
>> +				pte_clear_not_present_full(mm, addr, pte, tlb->fullmm);
>> +			} else if (is_hwpoison_entry(entry) ||
>> +				   is_swapin_error_entry(entry)) {
>> +				pte_clear_not_present_full(mm, addr, pte, tlb->fullmm);
> 
> Since it's been discussed and you're reposting a new version anyway, why
> not start with either reusing hwpoison or pte markers?  Or do you think it
> should be for future to drop the new swap entry again?
> 

IMHO if reusing hwpoison markers, there are some places that we need to distinguish them and do
different processing (and maybe also well comment them) which will make code more complicated and
somewhat hard to follow. And the "swapin error marker" here is most straightforward. And If pte markers
will support the "swapin error case" in the future, I think it's fine to change to use it then.
Does this make sense for you?

Thanks a lot!

> Thanks,
> 



  reply	other threads:[~2022-04-22  2:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-21 12:53 [PATCH v2 0/3] A few fixup patches for mm Miaohe Lin
2022-04-21 12:53 ` [PATCH v2 1/3] mm/swapfile: unuse_pte can map random data if swap read fails Miaohe Lin
2022-04-21 12:53 ` [PATCH v2 2/3] mm/swapfile: Fix lost swap bits in unuse_pte() Miaohe Lin
2022-04-21 13:13   ` David Hildenbrand
2022-04-21 13:50     ` Miaohe Lin
2022-04-21 12:53 ` [PATCH v2 3/3] mm/madvise: free hwpoison and swapin error entry in madvise_free_pte_range Miaohe Lin
2022-04-21 13:25   ` David Hildenbrand
2022-04-21 13:44     ` Miaohe Lin
2022-04-21 14:28   ` Peter Xu
2022-04-22  2:47     ` Miaohe Lin [this message]
2022-04-22  2:52       ` Peter Xu
2022-04-22  3:15         ` Miaohe Lin

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=d391b905-e017-5d0c-7485-2ea51d2587ae@huawei.com \
    --to=linmiaohe@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=david@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=naoya.horiguchi@nec.com \
    --cc=neilb@suse.de \
    --cc=peterx@redhat.com \
    --cc=sfr@canb.auug.org.au \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /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