[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200922062249.GA30831@lst.de>
Date: Tue, 22 Sep 2020 08:22:49 +0200
From: Christoph Hellwig <hch@....de>
To: Matthew Wilcox <willy@...radead.org>
Cc: Christoph Hellwig <hch@....de>,
Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Juergen Gross <jgross@...e.com>,
Stefano Stabellini <sstabellini@...nel.org>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Minchan Kim <minchan@...nel.org>,
Nitin Gupta <ngupta@...are.org>, x86@...nel.org,
xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
linux-mm@...ck.org
Subject: Re: [PATCH 3/6] drm/i915: use vmap in shmem_pin_map
On Mon, Sep 21, 2020 at 08:11:57PM +0100, Matthew Wilcox wrote:
> This is awkward. I'd like it if we had a vfree() variant which called
> put_page() instead of __free_pages(). I'd like it even more if we
> used release_pages() instead of our own loop that called put_page().
Note that we don't need a new vfree variant, we can do this manually if
we want, take a look at kernel/dma/remap.c. But I thought this code
intentionally doesn't want to do that to avoid locking in the memory
for the pages array. Maybe the i915 maintainers can clarify.
Powered by blists - more mailing lists