All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@linux.vnet.ibm.com>
To: Jonathan Corbet <corbet@lwn.net>
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: Wed, 12 Sep 2018 13:33:06 +0300	[thread overview]
Message-ID: <20180912103305.GC6719@rapoport-lnx> (raw)
In-Reply-To: <20180911115555.5fce5631@lwn.net>

On Tue, Sep 11, 2018 at 11:55:55AM -0600, Jonathan Corbet wrote:
> 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?

Well, I've amended the original text from gfp.h in attempt to make it more
"user friendly". The GFP_HIGHUSER became really confusing :)
I think that we can drop mentions of hardware from GFP_HIGHUSER_MOVABLE and
GFP_USER, but it makes sense to leave the example in the GFP_HIGHUSER
description.

How about:

    ``GFP_HIGHUSER_MOVABLE`` does not require that allocated memory
    will be directly accessible by the kernel 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. 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

 
> Thanks,
> 
> jon
> 

-- 
Sincerely yours,
Mike.


  reply	other threads:[~2018-09-12 10:33 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
2018-09-12 10:33     ` Mike Rapoport [this message]
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=20180912103305.GC6719@rapoport-lnx \
    --to=rppt@linux.vnet.ibm.com \
    --cc=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=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.