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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B9ECC433F5 for ; Fri, 11 Mar 2022 09:16:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 133188D0003; Fri, 11 Mar 2022 04:16:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0BD058D0001; Fri, 11 Mar 2022 04:16:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E9EF28D0003; Fri, 11 Mar 2022 04:16:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id D51938D0001 for ; Fri, 11 Mar 2022 04:16:13 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 96C9382035 for ; Fri, 11 Mar 2022 09:16:13 +0000 (UTC) X-FDA: 79231549026.10.8FFBFE4 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf04.hostedemail.com (Postfix) with ESMTP id D3F6940021 for ; Fri, 11 Mar 2022 09:16:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646990172; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EIGdPHjLg1hmetspOZdQaeJznczctW/NKNGy6+DAXDs=; b=UcdtxkZ0nU42xs84wkXeSqg5hsVAQXU72Gq9cdh0/yPjEKwptiEYktQ7KzWtuM1O+8JB6/ 4NHIYaQVafr0A675JjCIO7KYOLp4Rct/gdNoKg3u5xmjBoAr5Cee7OVQ/TNkbJYXkG4v/M MJwrXiljYtN1upzhsYAWme594iKu8UY= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-219-3w0YLyInOQGFHw3-62Sqdg-1; Fri, 11 Mar 2022 04:16:11 -0500 X-MC-Unique: 3w0YLyInOQGFHw3-62Sqdg-1 Received: by mail-wr1-f72.google.com with SMTP id p9-20020adf9589000000b001e333885ac1so2582866wrp.10 for ; Fri, 11 Mar 2022 01:16:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=EIGdPHjLg1hmetspOZdQaeJznczctW/NKNGy6+DAXDs=; b=gcyR5qdP7xLi8x/2bLrwFj4YZBk3DhFRxPwiqJ1L7h48YoERBDTMpXPwJq72dyEbY2 C+1YlvsVpMLAsW8uEAHijznc1dYdN8HcVTxvwM/lsrMy+NmkXKZIqXFAziEsIElbCN9D LNTfb1ZXHogzJppqqcytQf+tIZZDGZfDbKylCMzlscATIRqdWu/udBH+dSpuiYOD1aUp uvm9jEHCM/H5/kejhmoHaLp2od8cTUWdjat7188edQMuE1TQC+z8JrBLbAOCM/jriNdf emcuJregIXWelfbDbbGvQYaZFRI0iAcsRm1j/6PexsYT0nIf6H44MAJQArmS9gl1bBWN CH2g== X-Gm-Message-State: AOAM532UlHu3VgZW8tN4xrcOt13eZIHWE8oceA3iVtoMjgUQ4+mL+nn5 67Tv9ExiCl+GEjgVEqyRRpKRjHtPl93bkfd5a0eNilhJIFTiC4/plW1RkQpec1gGgqueM+YXoOf /2iNU7xQxfOk= X-Received: by 2002:a05:600c:4f0e:b0:389:eb27:581f with SMTP id l14-20020a05600c4f0e00b00389eb27581fmr2193341wmq.132.1646990169870; Fri, 11 Mar 2022 01:16:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJz66GE36RKglM3amxTnbF4SO/2NAriOwP++GkZh2LKs8fqberByaO4MYMTDcE67f9+yx5ejJw== X-Received: by 2002:a05:600c:4f0e:b0:389:eb27:581f with SMTP id l14-20020a05600c4f0e00b00389eb27581fmr2193321wmq.132.1646990169610; Fri, 11 Mar 2022 01:16:09 -0800 (PST) Received: from ?IPV6:2003:cb:c707:8200:163d:7a08:6e61:87a5? (p200300cbc7078200163d7a086e6187a5.dip0.t-ipconnect.de. [2003:cb:c707:8200:163d:7a08:6e61:87a5]) by smtp.gmail.com with ESMTPSA id a8-20020a05600c068800b00389bdc8c8c2sm6270654wmn.12.2022.03.11.01.16.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Mar 2022 01:16:09 -0800 (PST) Message-ID: <07401a0a-6878-6af2-f663-9f0c3c1d88e5@redhat.com> Date: Fri, 11 Mar 2022 10:16:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 To: Alex Sierra , jgg@nvidia.com Cc: Felix.Kuehling@amd.com, linux-mm@kvack.org, rcampbell@nvidia.com, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, hch@lst.de, jglisse@redhat.com, apopple@nvidia.com, willy@infradead.org, akpm@linux-foundation.org References: <20220310172633.9151-1-alex.sierra@amd.com> <20220310172633.9151-2-alex.sierra@amd.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v1 1/3] mm: split vm_normal_pages for LRU and non-LRU handling In-Reply-To: <20220310172633.9151-2-alex.sierra@amd.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=UcdtxkZ0; spf=none (imf04.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: D3F6940021 X-Stat-Signature: j4np5xp57ckf58qh59jibhpmgf456ar1 X-HE-Tag: 1646990172-777961 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 10.03.22 18:26, Alex Sierra wrote: > DEVICE_COHERENT pages introduce a subtle distinction in the way > "normal" pages can be used by various callers throughout the kernel. > They behave like normal pages for purposes of mapping in CPU page > tables, and for COW. But they do not support LRU lists, NUMA > migration or THP. Therefore we split vm_normal_page into two > functions vm_normal_any_page and vm_normal_lru_page. The latter will > only return pages that can be put on an LRU list and that support > NUMA migration, KSM and THP. > > We also introduced a FOLL_LRU flag that adds the same behaviour to > follow_page and related APIs, to allow callers to specify that they > expect to put pages on an LRU list. > I still don't see the need for s/vm_normal_page/vm_normal_any_page/. And as this patch is dominated by that change, I'd suggest (again) to just drop it as I don't see any value of that renaming. No specifier implies any. The general idea of this change LGTM. I wonder how this interacts with the actual DEVICE_COHERENT coherent series. Is this a preparation? Should it be part of the DEVICE_COHERENT series? IOW, should this patch start with "With DEVICE_COHERENT, we'll soon have vm_normal_pages() return device-managed anonymous pages that are not LRU pages. Although they behave like normal pages for purposes of mapping in CPU page, and for COW, they do not support LRU lists, NUMA migration or THP. [...]" But then, I'm confused by patch 2 and 3, because it feels more like we'd already have DEVICE_COHERENT then ("hmm_is_coherent_type"). -- Thanks, David / dhildenb