From: Jonathan Corbet <corbet@lwn.net>
To: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>,
Randy Dunlap <rdunlap@infradead.org>,
Matthew Wilcox <willy@infradead.org>,
Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/3] docs: core-api: add memory allocation guide
Date: Tue, 11 Sep 2018 11:55:55 -0600 [thread overview]
Message-ID: <20180911115555.5fce5631@lwn.net> (raw)
In-Reply-To: <1534517236-16762-4-git-send-email-rppt@linux.vnet.ibm.com>
Sorry for being so slow to get to this...it fell into a dark crack in my
rickety email folder hierarchy. I do have one question...
On Fri, 17 Aug 2018 17:47:16 +0300
Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
> + ``GFP_HIGHUSER_MOVABLE`` does not require that allocated memory
> + will be directly accessible by the kernel or the hardware and
> + implies that the data is movable.
> +
> + ``GFP_HIGHUSER`` means that the allocated memory is not movable,
> + but it is not required to be directly accessible by the kernel or
> + the hardware. An example may be a hardware allocation that maps
> + data directly into userspace but has no addressing limitations.
> +
> + ``GFP_USER`` means that the allocated memory is not movable and it
> + must be directly accessible by the kernel or the hardware. It is
> + typically used by hardware for buffers that are mapped to
> + userspace (e.g. graphics) that hardware still must DMA to.
I realize that this is copied from elsewhere, but still...as I understand
it, the "HIGH" part means that the allocation can be satisfied from high
memory, nothing more. So...it's irrelevant on 64-bit machines to start
with, right? And it has nothing to do with DMA, I would think. That would
be handled by the DMA infrastructure and, perhaps, the DMA* zones. Right?
I ask because high memory is an artifact of how things are laid out on
32-bit systems; hardware can often DMA quite easily into memory that the
kernel sees as "high". So, to me, this description seems kind of
confusing; I wouldn't mention hardware at all. But maybe I'm missing
something?
Thanks,
jon
next prev parent reply other threads:[~2018-09-11 17:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-17 14:47 [PATCH v3 0/3] docs/core-api: add memory allocation guide Mike Rapoport
2018-08-17 14:47 ` [PATCH v3 1/3] docs: core-api/gfp_mask-from-fs-io: add a label for cross-referencing Mike Rapoport
2018-08-17 14:47 ` [PATCH v3 2/3] docs: core-api/mm-api: add a lable for GFP flags section Mike Rapoport
2018-08-17 14:47 ` [PATCH v3 3/3] docs: core-api: add memory allocation guide Mike Rapoport
2018-09-11 17:55 ` Jonathan Corbet [this message]
2018-09-12 10:33 ` Mike Rapoport
2018-09-13 22:41 ` Jonathan Corbet
2018-09-03 5:12 ` [PATCH v3 0/3] docs/core-api: " Mike Rapoport
2018-09-11 16:24 ` Mike Rapoport
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=20180911115555.5fce5631@lwn.net \
--to=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=rdunlap@infradead.org \
--cc=rppt@linux.vnet.ibm.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.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.