All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Laurent Dufour <ldufour@linux.vnet.ibm.com>,
	linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org
Subject: Re: [PATCH next] powerpc/mm: fix _PAGE_PTE breaking swapoff
Date: Mon, 11 Jan 2016 11:25:59 +0530	[thread overview]
Message-ID: <87k2ngu0b4.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <87si24u32t.fsf@linux.vnet.ibm.com>

"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:

> Hugh Dickins <hughd@google.com> writes:
>
>> Swapoff after swapping hangs on the G5.  That's because the _PAGE_PTE
>> bit, added by set_pte_at(), is not expected by swapoff: so swap ptes
>> cannot be recognized.
>>
>> I'm not sure whether a swap pte should or should not have _PAGE_PTE set:
>> this patch assumes not, and fixes set_pte_at() to set _PAGE_PTE only on
>> present entries.
>
> One of the reason we added _PAGE_PTE is to enable HUGETLB migration. So
> we want migratio ptes to have _PAGE_PTE set.
>
>>
>> But if that's wrong, a reasonable alternative would be to
>> #define __pte_to_swp_entry(pte)	((swp_entry_t) { pte_val(pte) & ~_PAGE_PTE })
>> #define __swp_entry_to_pte(x)	__pte((x).val | _PAGE_PTE)
>>

You other email w.r.t soft dirty bits explained this. What I missed was
the fact that core kernel expect swp_entry_t to be of an arch neutral
format.  The confusing part was "arch_entry"

static inline pte_t swp_entry_to_pte(swp_entry_t entry)
{
	swp_entry_t arch_entry;
.....
}
	
IMHO we should use the alternative you suggested above. I can write a
patch with additional comments around that if you want me to do that.

-aneesh

WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Laurent Dufour <ldufour@linux.vnet.ibm.com>,
	linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org
Subject: Re: [PATCH next] powerpc/mm: fix _PAGE_PTE breaking swapoff
Date: Mon, 11 Jan 2016 11:25:59 +0530	[thread overview]
Message-ID: <87k2ngu0b4.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <87si24u32t.fsf@linux.vnet.ibm.com>

"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:

> Hugh Dickins <hughd@google.com> writes:
>
>> Swapoff after swapping hangs on the G5.  That's because the _PAGE_PTE
>> bit, added by set_pte_at(), is not expected by swapoff: so swap ptes
>> cannot be recognized.
>>
>> I'm not sure whether a swap pte should or should not have _PAGE_PTE set:
>> this patch assumes not, and fixes set_pte_at() to set _PAGE_PTE only on
>> present entries.
>
> One of the reason we added _PAGE_PTE is to enable HUGETLB migration. So
> we want migratio ptes to have _PAGE_PTE set.
>
>>
>> But if that's wrong, a reasonable alternative would be to
>> #define __pte_to_swp_entry(pte)	((swp_entry_t) { pte_val(pte) & ~_PAGE_PTE })
>> #define __swp_entry_to_pte(x)	__pte((x).val | _PAGE_PTE)
>>

You other email w.r.t soft dirty bits explained this. What I missed was
the fact that core kernel expect swp_entry_t to be of an arch neutral
format.  The confusing part was "arch_entry"

static inline pte_t swp_entry_to_pte(swp_entry_t entry)
{
	swp_entry_t arch_entry;
.....
}
	
IMHO we should use the alternative you suggested above. I can write a
patch with additional comments around that if you want me to do that.

-aneesh

--
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>

  parent reply	other threads:[~2016-01-11  5:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-10  0:50 [PATCH next] powerpc/mm: fix _PAGE_PTE breaking swapoff Hugh Dickins
2016-01-10  0:50 ` Hugh Dickins
2016-01-11  4:56 ` Aneesh Kumar K.V
2016-01-11  4:56   ` Aneesh Kumar K.V
2016-01-11  5:45   ` Hugh Dickins
2016-01-11  5:45     ` Hugh Dickins
2016-01-11  5:55   ` Aneesh Kumar K.V [this message]
2016-01-11  5:55     ` Aneesh Kumar K.V
2016-01-11  6:09     ` Hugh Dickins
2016-01-11  6:09       ` Hugh Dickins

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=87k2ngu0b4.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=ldufour@linux.vnet.ibm.com \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.