linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Rob Clark <robdclark@chromium.org>
Cc: Christoph Hellwig <hch@lst.de>,
	Mark Rutland <mark.rutland@arm.com>,
	Rob Clark <robdclark@gmail.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Sean Paul <sean@poorly.run>, David Airlie <airlied@linux.ie>,
	Daniel Vetter <daniel@ffwll.ch>,
	Allison Randal <allison@lohutok.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] drm: add cache support for arm64
Date: Fri, 9 Aug 2019 10:18:57 +0200	[thread overview]
Message-ID: <20190809081857.GB21967@lst.de> (raw)
In-Reply-To: <CAJs_Fx5fJ31CsFODBgBbhcCvoxSX_D1NHDjQs4LtJ_0GwuxMVA@mail.gmail.com>

On Thu, Aug 08, 2019 at 09:44:32AM -0700, Rob Clark wrote:
> > GFP_HIGHUSER basically just means that this is an allocation that could
> > dip into highmem, in which case it would not have a kernel mapping.
> > This can happen on arm + LPAE, but not on arm64.
> 
> Just a dumb question, but why is *all* memory in the linear map on
> arm64?  It would seem useful to have a source of pages that is not in
> the linear map.
> I guess it is mapped as huge pages (or something larger than 4k pages)?

In general that is just how the Linux kernel always worked, on all
architectures - we always had a linear mapping for all memory in the
kernel to make accessing it simple.  That started to break down a bit
with the 32-bit x86 PAE mode that supported more physical addressing
that virtual, which required the "high" memory to not be mapped into
the kernel direct mapping.  Similar schemes later showed up on various
other 32-bit architectures.

There is a patchset called XPFO that ensures memory is either in the
kernel direct map, or in userspace but not both to work around
speculation related vulnerabilities, but it has a pretty big performance
impact.

> Any recommended reading to understand how/why the kernel address space
> is setup the way it is (so I can ask fewer dumb questions)?

I don't really have a good pointer.  But usually there is just dumb
answers, not dumb questions.

  reply	other threads:[~2019-08-09  8:19 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-05 21:14 [PATCH 1/2] drm: add cache support for arm64 Rob Clark
2019-08-05 21:14 ` [PATCH 2/2] drm/msm: use drm_cache when available Rob Clark
2019-08-06  8:48 ` [PATCH 1/2] drm: add cache support for arm64 Christoph Hellwig
2019-08-06  9:38   ` Daniel Vetter
2019-08-06 11:38     ` Christoph Hellwig
2019-08-06 14:11   ` Rob Clark
2019-08-06 14:34     ` Mark Rutland
2019-08-06 16:31       ` Rob Clark
2019-08-07 12:38         ` Mark Rutland
2019-08-07 16:15           ` Rob Clark
2019-08-07 16:49             ` Mark Rutland
2019-08-07 17:30               ` Rob Clark
2019-08-08  7:59                 ` Christoph Hellwig
2019-08-08 16:44                   ` Rob Clark
2019-08-09  8:18                     ` Christoph Hellwig [this message]
2019-08-08  7:58               ` Christoph Hellwig
2019-08-08 10:20                 ` Mark Rutland
2019-08-08 10:24                   ` Mark Rutland
2019-08-08 10:32                   ` Will Deacon
2019-08-08  7:53           ` Christoph Hellwig
2019-08-06 15:50     ` Christoph Hellwig
2019-08-06 16:23       ` Rob Clark
2019-08-06 16:26         ` Rob Clark
2019-08-07  6:25         ` Christoph Hellwig
2019-08-07  8:48           ` Daniel Vetter
2019-08-08  9:55             ` Christoph Hellwig
2019-08-08 11:58               ` Daniel Vetter
2019-08-09  8:14                 ` Christoph Hellwig
2019-08-07 16:09           ` Rob Clark
2019-08-08 10:00             ` Christoph Hellwig
2019-08-08 16:32               ` Rob Clark

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=20190809081857.GB21967@lst.de \
    --to=hch@lst.de \
    --cc=airlied@linux.ie \
    --cc=allison@lohutok.net \
    --cc=catalin.marinas@arm.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mark.rutland@arm.com \
    --cc=maxime.ripard@bootlin.com \
    --cc=robdclark@chromium.org \
    --cc=robdclark@gmail.com \
    --cc=sean@poorly.run \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.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 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).