All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Price <steven.price@arm.com>
To: "Thomas Hellström (VMware)" <thomas_os@shipmail.org>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Thomas Hellstrom <thellstrom@vmware.com>
Subject: Re: [PATCH] mm/mapping_dirty_helpers: Update huge page-table entry callbacks
Date: Fri, 31 Jan 2020 11:33:08 +0000	[thread overview]
Message-ID: <20200131113307.GA34020@arm.com> (raw)
In-Reply-To: <20200131100052.58761-1-thomas_os@shipmail.org>

On Fri, Jan 31, 2020 at 10:00:52AM +0000, Thomas Hellström (VMware) wrote:
> From: Thomas Hellstrom <thellstrom@vmware.com>
> 
> Following the update of pagewalk code
> commit a07984d48146 ("mm: pagewalk: add p4d_entry() and pgd_entry()")
> we can modify the mapping_dirty_helpers' huge page-table entry callbacks
> to avoid splitting when a huge pud or -pmd is encountered.
> 
> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
> Cc: Steven Price <steven.price@arm.com>

LGTM

Reviewed-by: Steven Price <steven.price@arm.com>

> ---
>  mm/mapping_dirty_helpers.c | 42 ++++++++++++++++++++++++++++++++++----
>  1 file changed, 38 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/mapping_dirty_helpers.c b/mm/mapping_dirty_helpers.c
> index 71070dda9643..2c7d03675903 100644
> --- a/mm/mapping_dirty_helpers.c
> +++ b/mm/mapping_dirty_helpers.c
> @@ -111,26 +111,60 @@ static int clean_record_pte(pte_t *pte, unsigned long addr,
>  	return 0;
>  }
>  
> -/* wp_clean_pmd_entry - The pagewalk pmd callback. */
> +/*
> + * wp_clean_pmd_entry - The pagewalk pmd callback.
> + *
> + * Dirty-tracking should take place on the PTE level, so
> + * WARN() if encountering a dirty huge pmd.
> + * Furthermore, never split huge pmds, since that currently
> + * causes dirty info loss. The pagefault handler should do
> + * that if needed.
> + */
>  static int wp_clean_pmd_entry(pmd_t *pmd, unsigned long addr, unsigned long end,
>  			      struct mm_walk *walk)
>  {
> -	/* Dirty-tracking should be handled on the pte level */
>  	pmd_t pmdval = pmd_read_atomic(pmd);
>  
> +	if (!pmd_trans_unstable(&pmdval))
> +		return 0;
> +
> +	if (pmd_none(pmdval)) {
> +		walk->action = ACTION_AGAIN;
> +		return 0;
> +	}
> +
> +	/* Huge pmd, present or migrated */
> +	walk->action = ACTION_CONTINUE;
>  	if (pmd_trans_huge(pmdval) || pmd_devmap(pmdval))
>  		WARN_ON(pmd_write(pmdval) || pmd_dirty(pmdval));
>  
>  	return 0;
>  }
>  
> -/* wp_clean_pud_entry - The pagewalk pud callback. */
> +/*
> + * wp_clean_pud_entry - The pagewalk pud callback.
> + *
> + * Dirty-tracking should take place on the PTE level, so
> + * WARN() if encountering a dirty huge puds.
> + * Furthermore, never split huge puds, since that currently
> + * causes dirty info loss. The pagefault handler should do
> + * that if needed.
> + */
>  static int wp_clean_pud_entry(pud_t *pud, unsigned long addr, unsigned long end,
>  			      struct mm_walk *walk)
>  {
> -	/* Dirty-tracking should be handled on the pte level */
>  	pud_t pudval = READ_ONCE(*pud);
>  
> +	if (!pud_trans_unstable(&pudval))
> +		return 0;
> +
> +	if (pud_none(pudval)) {
> +		walk->action = ACTION_AGAIN;
> +		return 0;
> +	}
> +
> +	/* Huge pud */
> +	walk->action = ACTION_CONTINUE;
>  	if (pud_trans_huge(pudval) || pud_devmap(pudval))
>  		WARN_ON(pud_write(pudval) || pud_dirty(pudval));
>  
> -- 
> 2.21.1
> 


  reply	other threads:[~2020-01-31 11:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31 10:00 [PATCH] mm/mapping_dirty_helpers: Update huge page-table entry callbacks Thomas Hellström (VMware)
2020-01-31 11:33 ` Steven Price [this message]
2020-01-31 14:55   ` Thomas Hellström (VMware)
  -- strict thread matches above, loose matches on Subject: below --
2020-02-03 15:43 Thomas Hellström (VMware)

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=20200131113307.GA34020@arm.com \
    --to=steven.price@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=thellstrom@vmware.com \
    --cc=thomas_os@shipmail.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 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.