[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 8 Aug 2019 02:23:14 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Christoph Hellwig <hch@....de>
Cc: Hugh Dickins <hughd@...gle.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Chris Wilson <chris@...is-wilson.co.uk>,
David Howells <dhowells@...hat.com>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCHv2 2/3] i915: convert to new mount API
On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
> On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> > Though personally I'm averse to managing "f"objects through
> > "m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works
> > on the virtual address of a mapping, but the huge-or-not alignment of
> > that mapping must have been decided previously). In Google we do use
> > fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis -
> > one day I'll get to upstreaming those.
>
> Such an interface seems very useful, although the two fcntls seem a bit
> odd.
>
> But I think the point here is that the i915 has its own somewhat odd
> instance of tmpfs. If we could pass the equivalent of the huge=*
> options to shmem_file_setup all that garbage (including the
> shmem_file_setup_with_mnt function) could go away.
... or follow shmem_file_super() with whatever that fcntl maps to
internally. I would really love to get rid of that i915 kludge.
Powered by blists - more mailing lists