Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1543126 > unrolled thread

Re: [PATCH 3/3] mm: make pagoff_t type 64-bit

Started byArnd Bergmann <arnd@arndb.de>
First post2016-12-16 00:20 +0100
Last post2016-12-18 10:40 +0100
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 3/3] mm: make pagoff_t type 64-bit Arnd Bergmann <arnd@arndb.de> - 2016-12-16 00:20 +0100
    Re: [PATCH 3/3] mm: make pagoff_t type 64-bit Arnd Bergmann <arnd@arndb.de> - 2016-12-16 12:10 +0100
    Re: [PATCH 3/3] mm: make pagoff_t type 64-bit Christoph Hellwig <hch@lst.de> - 2016-12-18 10:40 +0100

#1543126 — Re: [PATCH 3/3] mm: make pagoff_t type 64-bit

FromArnd Bergmann <arnd@arndb.de>
Date2016-12-16 00:20 +0100
SubjectRe: [PATCH 3/3] mm: make pagoff_t type 64-bit
Message-ID<sONtE-3G8-9@gated-at.bofh.it>
On Sunday, December 11, 2016 6:26:42 PM CET Yury Norov wrote:
> Also fix related interfaces
> 
> Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
> ---
>  fs/btrfs/extent_io.c       | 2 +-
>  fs/ext2/dir.c              | 4 ++--
>  include/linux/mm.h         | 9 +++++----
>  include/linux/radix-tree.h | 8 ++++----
>  include/linux/types.h      | 2 +-
>  lib/radix-tree.c           | 8 ++++----
>  mm/debug.c                 | 2 +-
>  mm/internal.h              | 2 +-
>  mm/memory.c                | 4 ++--
>  mm/mmap.c                  | 7 ++++---
>  mm/readahead.c             | 4 ++--
>  mm/util.c                  | 3 ++-
>  12 files changed, 29 insertions(+), 26 deletions(-)
> 

Thanks Yury for the demonstration. I think this would put the nail
in the coffin of the idea of mmap64 even for Pavel, who didn't
seem convinced already.

Changing all those interfaces and structure, struct page in particular,
is clearly too costly for any advantage we might have otherwise
gained.

	Arnd

[toc] | [next] | [standalone]


#1543374

FromArnd Bergmann <arnd@arndb.de>
Date2016-12-16 12:10 +0100
Message-ID<sOYyK-2L0-31@gated-at.bofh.it>
In reply to#1543126
On Friday, December 16, 2016 4:25:14 PM CET Yury Norov wrote:
> On Sun, Dec 11, 2016 at 03:59:01PM +0100, Arnd Bergmann wrote:
> > On Sunday, December 11, 2016 6:26:42 PM CET Yury Norov wrote:
> > > Also fix related interfaces
> > > 
> > > Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
> > 
> > Thanks Yury for the demonstration. I think this would put the nail
> > in the coffin of the idea of mmap64 even for Pavel, who didn't
> > seem convinced already.
> > 
> > Changing all those interfaces and structure, struct page in particular,
> > is clearly too costly for any advantage we might have otherwise
> > gained.
> > 
> >       Arnd
> 
> To be complete, we have 3 options:
>  1 leave things as is. 32-bit architectures will have no option to
>    mmap big offsets, and no one cares - as usual.
>  2 add mmap64() for compat arches only. This way we don't need patch
>    3, and arches like aarch32 or aarch64/ilp32 will enjoy true 64-bit
>    offsets.
>  3 introduce CONFIG_64_BIT_PGOFF_T, and let Pavel enable it if he has
>    to work with big files on 32-bit arches.
> 
> The most realistic approach for me is 1 because I never heard about
> 64-bit pgoff_t requests, except Pavel's one. Thinking about
> aarch64/ilp32, we probably need second approach. This is only 2 simple
> patches that are already there, and one patch in glibc. It will let
> 32-bit software work in 64-bit environment more smoothly. Cavium
> people should be completely satisfied with 2.

Agreed: If there is a serious request from Cavium or Huawei (which
are also very interested in this feature) and a specific use case,
we can still do 2 easily.

> Third is more looking like research exercise than something we need
> in practice.

Right.

> The only thing that makes me sad is that we proudly declare 64-bit
> off_t in new 32-bit ABIs but in fact we lie, at least in this
> specific case. We should add corresponding checks on glibc side at
> least. It's also simple.

Well, the only thing we are really saying there is that we support
more than 32-bit, and that the ABI uses 64-bit. Actually doing 64-bit
offsets within (very sparse) files probably also fails on 64-bit
architectures, at least on some file systems.

	Arnd

[toc] | [prev] | [next] | [standalone]


#1544112

FromChristoph Hellwig <hch@lst.de>
Date2016-12-18 10:40 +0100
Message-ID<sPG6J-601-9@gated-at.bofh.it>
In reply to#1543126
On Fri, Dec 16, 2016 at 04:25:14PM +0530, Yury Norov wrote:
>  1 leave things as is. 32-bit architectures will have no option to
>    mmap big offsets, and no one cares - as usual.

And that's the only sensible option.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web