linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Yin Fengwei <fengwei.yin@intel.com>
Cc: david@redhat.com, linux-mm@kvack.org, dave.hansen@intel.com,
	tim.c.chen@intel.com, ying.huang@intel.com
Subject: Re: [RFC PATCH 2/5] filemap: do file page mapping with folio granularity
Date: Mon, 30 Jan 2023 13:35:45 +0000	[thread overview]
Message-ID: <Y9fHsaTEQAfyqxIG@casper.infradead.org> (raw)
In-Reply-To: <20230130125504.2509710-3-fengwei.yin@intel.com>

On Mon, Jan 30, 2023 at 08:55:01PM +0800, Yin Fengwei wrote:
> Add function to do file page mapping based on folio and update
> filemap_map_pages() to use new function. So the filemap page
> mapping will deal with folio granularity instead of page
> granularity. This allow batched folio refcount update.
> 
> Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
> ---
>  mm/filemap.c | 82 ++++++++++++++++++++++++++++++----------------------
>  1 file changed, 48 insertions(+), 34 deletions(-)
> 
> diff --git a/mm/filemap.c b/mm/filemap.c
> index c915ded191f0..fe0c226c8b1e 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -3351,6 +3351,43 @@ static inline struct folio *next_map_page(struct address_space *mapping,
>  				  mapping, xas, end_pgoff);
>  }
>  
> +

I'd remove this blank line, we typically only have one blank line
between functions.

> +static vm_fault_t filemap_map_folio_range(struct vm_fault *vmf,
> +	struct folio *folio, struct page *page, unsigned long addr,
> +	int len)

I see this under-indentation in other parts of the mm and it drives me
crazy.  Two tabs to indent the arguments please, otherwise they look
like part of the function.

Also, 'len' is ambiguous.  I'd call this 'nr' or 'nr_pages'.  Also
it should be an unsigned int.

> +{
> +	vm_fault_t ret = 0;
> +	struct vm_area_struct *vma = vmf->vma;
> +	struct file *file = vma->vm_file;
> +	unsigned int mmap_miss = READ_ONCE(file->f_ra.mmap_miss);
> +	int ref_count = 0, count = 0;

Also make these unsigned.

> -		/*
> -		 * NOTE: If there're PTE markers, we'll leave them to be
> -		 * handled in the specific fault path, and it'll prohibit the
> -		 * fault-around logic.
> -		 */

I'd rather not lose this comment; can you move it into
filemap_map_folio_range() please?

> -		if (!pte_none(*vmf->pte))
> -			goto unlock;
> -
> -		/* We're about to handle the fault */
> -		if (vmf->address == addr)
> +		if (VM_FAULT_NOPAGE ==
> +			filemap_map_folio_range(vmf, folio, page, addr, len))
>  			ret = VM_FAULT_NOPAGE;

That indentation is also confusing.  Try this:

		if (filemap_map_folio_range(vmf, folio, page, addr, len) ==
				VM_FAULT_NOPAGE)
			ret = VM_FAULT_NOPAGE;

Except there's an easier way to write it:

		ret |= filemap_map_folio_range(vmf, folio, page, addr, len);


Thanks for doing this!  Looks so much better and performs better!


  reply	other threads:[~2023-01-30 13:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-30 12:54 [RFC PATCH 0/5] folio based filemap_map_pages() Yin Fengwei
2023-01-30 12:55 ` [RFC PATCH 1/5] mm: Enable fault around for shared file page fault Yin Fengwei
2023-01-30 13:21   ` Matthew Wilcox
2023-01-31  0:59     ` Yin, Fengwei
2023-01-30 12:55 ` [RFC PATCH 2/5] filemap: do file page mapping with folio granularity Yin Fengwei
2023-01-30 13:35   ` Matthew Wilcox [this message]
2023-01-31  1:03     ` Yin, Fengwei
2023-01-31  3:34   ` Huang, Ying
2023-01-31  6:32     ` Yin, Fengwei
2023-01-30 12:55 ` [RFC PATCH 3/5] rmap: add page_add_file_rmap_range() Yin Fengwei
2023-01-30 13:50   ` Matthew Wilcox
2023-01-31  7:24   ` Huang, Ying
2023-01-31  7:48     ` Yin, Fengwei
2023-01-30 12:55 ` [RFC PATCH 4/5] mm: add do_set_pte_entry() Yin Fengwei
2023-01-30 13:53   ` Matthew Wilcox
2023-01-31  1:06     ` Yin, Fengwei
2023-01-30 12:55 ` [RFC PATCH 5/5] filemap: batched update mm counter,rmap when map file folio Yin Fengwei
2023-01-30 14:14   ` Matthew Wilcox
2023-01-31  1:11     ` Yin, Fengwei
2023-01-30 12:58 ` [RFC PATCH 0/5] folio based filemap_map_pages() Yin, Fengwei

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=Y9fHsaTEQAfyqxIG@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=dave.hansen@intel.com \
    --cc=david@redhat.com \
    --cc=fengwei.yin@intel.com \
    --cc=linux-mm@kvack.org \
    --cc=tim.c.chen@intel.com \
    --cc=ying.huang@intel.com \
    /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