From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1204C433E1 for ; Thu, 25 Mar 2021 17:52:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7E99361A2E for ; Thu, 25 Mar 2021 17:52:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230046AbhCYRvh (ORCPT ); Thu, 25 Mar 2021 13:51:37 -0400 Received: from ste-pvt-msa1.bahnhof.se ([213.80.101.70]:65309 "EHLO ste-pvt-msa1.bahnhof.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229547AbhCYRvf (ORCPT ); Thu, 25 Mar 2021 13:51:35 -0400 Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTP id D83553F6BE; Thu, 25 Mar 2021 18:51:32 +0100 (CET) Authentication-Results: ste-pvt-msa1.bahnhof.se; dkim=pass (1024-bit key; unprotected) header.d=shipmail.org header.i=@shipmail.org header.b=JBnbqbi6; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at bahnhof.se Received: from ste-pvt-msa1.bahnhof.se ([127.0.0.1]) by localhost (ste-pvt-msa1.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kY9Ut-ckC-Gq; Thu, 25 Mar 2021 18:51:32 +0100 (CET) Received: by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTPA id 4EE033F6BD; Thu, 25 Mar 2021 18:51:30 +0100 (CET) Received: from [10.249.254.165] (unknown [192.198.151.44]) by mail1.shipmail.org (Postfix) with ESMTPSA id 0260136059E; Thu, 25 Mar 2021 18:51:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shipmail.org; s=mail; t=1616694689; bh=yIsgeu3PLt8B2VGA2PrEalyxmaXCbDHFpjtAUnLL9Yw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=JBnbqbi6vAuhfNq/HXjPBCfOFBgsOv10wheSeNLjPxUBRzniauAhbotYnLpZKS5of VzDkBxo66te4Sj4rNot5UYM51RfgpdnJ2dg9WoEkck6bv5nBae6UuIPg0WTyScmDLV TQpYoEl+eJeA1RqYhIszPNut6dMI2YjHDODfaDpY= Subject: Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages To: Dave Hansen , "Williams, Dan J" , "dri-devel@lists.freedesktop.org" , "christian.koenig@amd.com" , "jgg@nvidia.com" , "airlied@linux.ie" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" References: <20210321184529.59006-1-thomas_os@shipmail.org> <20210321184529.59006-2-thomas_os@shipmail.org> <75423f64-adef-a2c4-8e7d-2cb814127b18@intel.com> <6b0de827-738d-b3c5-fc79-8ca9047bad35@intel.com> From: =?UTF-8?Q?Thomas_Hellstr=c3=b6m_=28Intel=29?= Message-ID: <9f789d64-940f-c728-8d5e-aab74d562fb6@shipmail.org> Date: Thu, 25 Mar 2021 18:51:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <6b0de827-738d-b3c5-fc79-8ca9047bad35@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/24/21 9:25 PM, Dave Hansen wrote: > On 3/24/21 1:22 PM, Thomas Hellström (Intel) wrote: >>> 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 */ >>> >> OK, I'll follow your advise here. FWIW I grepped for SW1 and it seems >> used in a selftest, but only for PTEs AFAICT. >> >> Oh, and we don't care about 32-bit much anymore? > On x86, we have 64-bit PTEs when running 32-bit kernels if PAE is > enabled. IOW, we can handle the majority of 32-bit CPUs out there. > > But, yeah, we don't care about 32-bit. :) Hmm, Actually it makes some sense to use SW1, to make it end up in the same dword as the PSE bit, as from what I can tell, reading of a 64-bit pmd_t on 32-bit PAE is not atomic, so in theory a huge pmd could be modified while reading the pmd_t making the dwords inconsistent.... How does that work with fast gup anyway? In any case, what would be the best cause of action here? Use SW1 or disable completely for 32-bit? /Thomas