[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <75423f64-adef-a2c4-8e7d-2cb814127b18@intel.com>
Date: Wed, 24 Mar 2021 09:34:48 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Thomas Hellström (Intel)
<thomas_os@...pmail.org>,
"Williams, Dan J" <dan.j.williams@...el.com>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"christian.koenig@....com" <christian.koenig@....com>,
"jgg@...dia.com" <jgg@...dia.com>,
"airlied@...ux.ie" <airlied@...ux.ie>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages
On 3/24/21 3:05 AM, Thomas Hellström (Intel) wrote:
> Yes, I agree. Seems like the special (SW1) is available also for huge
> page table entries on x86 AFAICT, although just not implemented.
> Otherwise the SW bits appear completely used up.
Although the _PAGE_BIT_SOFTW* bits are used up, there's plenty of room
in the hardware PTEs. Bits 52->58 are software-available, and we're
only using 58 at the moment.
We also have not been careful at *all* about how _PAGE_BIT_SOFTW* are
used. It's quite possible we can encode another use even in the
existing bits.
Personally, I'd just try:
#define _PAGE_BIT_SOFTW5 57 /* available for programmer */
Powered by blists - more mailing lists