All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Ira Weiny <ira.weiny@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dave Hansen <dave.hansen@intel.com>,
	Christoph Hellwig <hch@infradead.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Eric Biggers <ebiggers@kernel.org>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH V2 2/2] mm/highmem: Lift memcpy_[to|from]_page to core
Date: Tue, 8 Dec 2020 16:40:55 +0000	[thread overview]
Message-ID: <20201208164055.GI7338@casper.infradead.org> (raw)
In-Reply-To: <20201208163814.GN1563847@iweiny-DESK2.sc.intel.com>

On Tue, Dec 08, 2020 at 08:38:14AM -0800, Ira Weiny wrote:
> On Tue, Dec 08, 2020 at 12:23:16PM +0000, Matthew Wilcox wrote:
> > On Mon, Dec 07, 2020 at 02:57:03PM -0800, ira.weiny@intel.com wrote:
> > > Placing these functions in 'highmem.h' is suboptimal especially with the
> > > changes being proposed in the functionality of kmap.  From a caller
> > > perspective including/using 'highmem.h' implies that the functions
> > > defined in that header are only required when highmem is in use which is
> > > increasingly not the case with modern processors.  Some headers like
> > > mm.h or string.h seem ok but don't really portray the functionality
> > > well.  'pagemap.h', on the other hand, makes sense and is already
> > > included in many of the places we want to convert.
> > 
> > pagemap.h is for the page cache.  It's not for "random page
> > functionality".  Yes, I know it's badly named.  No, I don't want to
> > rename it.  These helpers should go in highmem.h along with zero_user().
> 
> I could have sworn you suggested pagemap.h.  But I can't find the evidence on
> lore.  :-/   hehehe...
> 
> In the end the code does not care.  I have a distaste for highmem.h because it
> is no longer for 'high memory'.  And I think a number of driver writers who are
> targeting 64bit platforms just don't care any more.  So as we head toward
> memory not being mapped by the kernel for other reasons I think highmem needs
> to be 'rebranded' if not renamed.

Rename highmem.h to kmap.h?

      reply	other threads:[~2020-12-08 16:42 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-07 22:57 [PATCH V2 0/2] Lift memcpy_[to|from]_page to core ira.weiny
2020-12-07 22:57 ` [PATCH V2 1/2] mm/highmem: Remove deprecated kmap_atomic ira.weiny
2020-12-08  0:22   ` kernel test robot
2020-12-08  0:22     ` kernel test robot
2020-12-07 22:57 ` [PATCH V2 2/2] mm/highmem: Lift memcpy_[to|from]_page to core ira.weiny
2020-12-07 23:26   ` Matthew Wilcox
2020-12-07 23:34     ` Dan Williams
2020-12-07 23:40       ` Matthew Wilcox
2020-12-07 23:49         ` Dan Williams
2020-12-08 21:32           ` Ira Weiny
2020-12-08 21:50             ` Matthew Wilcox
2020-12-08 22:23               ` Dan Williams
2020-12-08 22:32                 ` Matthew Wilcox
2020-12-08 22:45                   ` Darrick J. Wong
2020-12-08 22:54                     ` Matthew Wilcox
2020-12-08 23:40                     ` Dan Williams
2020-12-09  2:22                       ` Ira Weiny
2020-12-09  4:03                         ` Matthew Wilcox
2020-12-09 19:47                           ` Dan Williams
2020-12-09 20:14                             ` Matthew Wilcox
2020-12-09 20:19                               ` Dan Williams
2020-12-10  5:35                               ` Ira Weiny
2020-12-08 22:21             ` Dan Williams
2020-12-08  0:40   ` kernel test robot
2020-12-08  0:40     ` kernel test robot
2020-12-08  1:09   ` kernel test robot
2020-12-08  1:09     ` kernel test robot
2020-12-08 12:23   ` Matthew Wilcox
2020-12-08 16:38     ` Ira Weiny
2020-12-08 16:40       ` Matthew Wilcox [this message]

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=20201208164055.GI7338@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=ebiggers@kernel.org \
    --cc=hch@infradead.org \
    --cc=ira.weiny@intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    /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.