From: Catalin Marinas <catalin.marinas@arm.com>
To: Alexander Potapenko <glider@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Kees Cook <keescook@chromium.org>,
Will Deacon <will.deacon@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: define __alloc_zeroed_user_highpage
Date: Fri, 13 Mar 2020 15:03:00 +0000 [thread overview]
Message-ID: <20200313150300.GD3857972@arrakis.emea.arm.com> (raw)
In-Reply-To: <CAG_fn=VfRW6Gi-a9WCMwoK1-Nc+i+NFLN3ZyhFAUzr-K3LeaZQ@mail.gmail.com>
On Thu, Mar 12, 2020 at 08:59:28PM +0100, Alexander Potapenko wrote:
> On Thu, Mar 12, 2020 at 5:49 PM Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > On Thu, Mar 12, 2020 at 04:59:20PM +0100, glider@google.com wrote:
> > > When running the kernel with init_on_alloc=1, calling the default
> > > implementation of __alloc_zeroed_user_highpage() from include/linux/highmem.h
> > > leads to double-initialization of the allocated page (first by the page
> > > allocator, then by clear_user_page().
> > > Calling alloc_page_vma() with __GFP_ZERO, similarly to e.g. x86, seems
> > > to be enough to ensure the user page is zeroed only once.
> >
> > Just to check, is there a functional ussue beyond the redundant zeroing,
> > or is this jsut a performance issue?
>
> This is just a performance issue that only manifests when running the
> kernel with init_on_alloc=1.
>
> > On architectures with real highmem, does GFP_HIGHUSER prevent the
> > allocator from zeroing the page in this case, or is the architecture
> > prevented from allocating from highmem?
>
> I was hoping one of ARM maintainers can answer this question. My
> understanding was that __GFP_ZERO should be sufficient, but there's
> probably something I'm missing.
On architectures with aliasing D-cache (whether it's VIVT or aliasing
VIPT), clear_user_highpage() ensures that the correct alias, as seen by
the user, is cleared (see the arm32 v6_clear_user_highpage_aliasing() as
an example). The clear_highpage() call as done by page_alloc.c does not
have the user address information, so it can only clear the kernel
alias.
On arm64 we don't have such issue, so we can optimise this case as per
your patch. We may change this function later with MTE if we allow tags
other than 0 on the first allocation of anonymous pages.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-03-13 15:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-12 15:59 [PATCH] arm64: define __alloc_zeroed_user_highpage glider
2020-03-12 16:49 ` Mark Rutland
2020-03-12 19:59 ` Alexander Potapenko
2020-03-13 15:03 ` Catalin Marinas [this message]
2020-03-17 18:37 ` Catalin Marinas
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=20200313150300.GD3857972@arrakis.emea.arm.com \
--to=catalin.marinas@arm.com \
--cc=akpm@linux-foundation.org \
--cc=glider@google.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=will.deacon@arm.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;
as well as URLs for NNTP newsgroup(s).