lkml.org 
[lkml]   [2020]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 6/8] mm, clear_huge_page: use clear_page_uncached() for gigantic pages

* Ankur Arora <ankur.a.arora@oracle.com> wrote:

> Uncached writes are suitable for circumstances where the region written to
> is not expected to be read again soon, or the region written to is large
> enough that there's no expectation that we will find the writes in the
> cache.
>
> Accordingly switch to using clear_page_uncached() for gigantic pages.
>
> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
> ---
> mm/memory.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index eeae590e526a..4d2c58f83ab1 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -5092,7 +5092,7 @@ static void clear_gigantic_page(struct page *page,
> for (i = 0; i < pages_per_huge_page;
> i++, p = mem_map_next(p, page, i)) {
> cond_resched();
> - clear_user_highpage(p, addr + i * PAGE_SIZE);
> + clear_user_highpage_uncached(p, addr + i * PAGE_SIZE);
> }
> }

So this does the clearing in 4K chunks, and your measurements suggest that
short memory clearing is not as efficient, right?

I'm wondering whether it would make sense to do 2MB chunked clearing on
64-bit CPUs, instead of 512x 4k clearing? Both 2MB and GB pages are
continuous in memory, so accessible to these instructions in a single
narrow loop.

Thanks,

Ingo

\
 
 \ /
  Last update: 2020-10-14 17:29    [W:0.167 / U:0.668 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site