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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8AE89C433FE for ; Wed, 13 Apr 2022 11:38:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235229AbiDMLlC (ORCPT ); Wed, 13 Apr 2022 07:41:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37266 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235246AbiDMLk5 (ORCPT ); Wed, 13 Apr 2022 07:40:57 -0400 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3F9605C352 for ; Wed, 13 Apr 2022 04:38:30 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id b21so2984609lfb.5 for ; Wed, 13 Apr 2022 04:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ZsUJ2NINlf/YGW3oKuUtDCOd4WHYH6lv9r94E8nLe7k=; b=uxdU90BlQLxm0jDBpwT7ZMBvjlYIIiuIeQRT3hGbatcT1HUweuug/AHiWZ/ufhqwGo mVAjin2rGuacjH0++numKLzwazoDwfSff0NMvZVnuAPgoMJbqvDy1edfuAy40M8BFC/x a3laDOVAcLJR3IqFtnn+Amrp1MEceVLZ4500Kf78sVczEg4lQrTkzpiTM7sGu7TF/IL1 MrG+dTFhVE/Z0ag7oNkra0VOAz8vP+9DIsrR7yV5mXS7nXj3rXbXcUt96Tg/WxcJ5oe7 D66RiJa98VTqhO3o+k7IwlPhz5/uW8Mzr89bUA/hjNBYKp6JqGfad4ttcKn8J102HYgP mZKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ZsUJ2NINlf/YGW3oKuUtDCOd4WHYH6lv9r94E8nLe7k=; b=4MVo2Yik/FzkYAh1Wrl+3YGljoLJI3BfU9Ws/CyzMiTWzIkMva9siWEgq+vB1+Lxb9 iwb2BLt47Whn4y2wbd+SmYrkYteeiQIXLB8hzsnBIDPhTwzK5td0IGm+nx0R/OdeAJzN qa3EDMt64itXOipSkpiiF8gZU2auqf7KQ5Xe7zjdmC7ft3uxfco0XS9GApMu5+XNobDS 1lckQSx+JlsyoqSIk88J4WDNGs8D8DDE3nQ0/2UPsXlf7HBRAj5oTU2+5kLVdZg1DWe1 Bc0hslCvihE2anXDNo4bTaf45R8uORN20BYLbcrBmKAVxvxWSCboEVWOLm6NdE5WR3xM BGRA== X-Gm-Message-State: AOAM530ug5naF6YIAOaFchvSimWgqdH1MKiGOJvcAme4BdgXjM+A1buH jWsA6gJubBHP4m1N2hk68XlWZg== X-Google-Smtp-Source: ABdhPJyqOiwPXY3JcLiTivxhds7PtI4vfS0IEt8zlViK9HOGTpUtfBt/VR8j//JV+OX1VzpzOxSuGQ== X-Received: by 2002:a19:4953:0:b0:46b:bdc2:860a with SMTP id l19-20020a194953000000b0046bbdc2860amr4567387lfj.6.1649849908414; Wed, 13 Apr 2022 04:38:28 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id k5-20020a196f05000000b0046b94269595sm1503056lfc.169.2022.04.13.04.38.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Apr 2022 04:38:28 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id DF1E510369B; Wed, 13 Apr 2022 14:40:01 +0300 (+03) Date: Wed, 13 Apr 2022 14:40:01 +0300 From: "Kirill A. Shutemov" To: Mike Rapoport Cc: Dave Hansen , "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , Brijesh Singh , David Hildenbrand , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, Mike Rapoport Subject: Re: [PATCHv4 1/8] mm: Add support for unaccepted memory Message-ID: <20220413114001.wdsi2xrm4btrghms@box.shutemov.name> References: <20220405234343.74045-1-kirill.shutemov@linux.intel.com> <20220405234343.74045-2-kirill.shutemov@linux.intel.com> <767c2100-c171-1fd3-6a92-0af2e4bf3067@intel.com> <20220409155423.iv2arckmvavvpegt@box.shutemov.name> <6c976344-fdd6-95cd-2cb0-b0e817bf0392@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 11, 2022 at 01:07:29PM +0300, Mike Rapoport wrote: > On Sun, Apr 10, 2022 at 11:38:08PM -0700, Dave Hansen wrote: > > On 4/9/22 08:54, Kirill A. Shutemov wrote: > > > On Fri, Apr 08, 2022 at 11:55:43AM -0700, Dave Hansen wrote: > > > > >>> if (fpi_flags & FPI_TO_TAIL) > > >>> to_tail = true; > > >>> else if (is_shuffle_order(order)) > > >>> @@ -1149,7 +1192,8 @@ static inline void __free_one_page(struct page *page, > > >>> static inline bool page_expected_state(struct page *page, > > >>> unsigned long check_flags) > > >>> { > > >>> - if (unlikely(atomic_read(&page->_mapcount) != -1)) > > >>> + if (unlikely(atomic_read(&page->_mapcount) != -1) && > > >>> + !PageUnaccepted(page)) > > >>> return false; > > >> > > >> That probably deserves a comment, and maybe its own if() statement. > > > > > > Own if does not work. PageUnaccepted() is encoded in _mapcount. > > > > > > What about this: > > > > > > /* > > > * page->_mapcount is expected to be -1. > > > * > > > * There is an exception for PageUnaccepted(). The page type can be set > > > * for pages on free list. Page types are encoded in _mapcount. > > > * > > > * PageUnaccepted() will get cleared in post_alloc_hook(). > > > */ > > > if (unlikely((atomic_read(&page->_mapcount) | PG_unaccepted) != -1)) > > Maybe I'm missing something, but isn't this true for any PageType? > > > > return false; > > > > > > ? > > > > That's better. But, aren't the PG_* names usually reserved for real > > page->flags bits? That naming might be part of my confusion. > > We use them for PageType as well like PG_buddy, PG_offline, PG_Table. PG_buddy gets clear on remove from the free list, before the chec. PG_offline and PG_table pages are never on free lists. -- Kirill A. Shutemov