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 0C502C433EF for ; Wed, 1 Jun 2022 12:14:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81D318D000D; Wed, 1 Jun 2022 08:14:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CC588D0006; Wed, 1 Jun 2022 08:14:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66AB58D000D; Wed, 1 Jun 2022 08:14:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 57CD48D0006 for ; Wed, 1 Jun 2022 08:14:38 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1D4DE33B60 for ; Wed, 1 Jun 2022 12:14:38 +0000 (UTC) X-FDA: 79529560236.05.70A5EEF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf24.hostedemail.com (Postfix) with ESMTP id 104DA180050 for ; Wed, 1 Jun 2022 12:14:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654085676; 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=lMUArCTwyhl0gL8o4f4vz4ehSKmCnNPpyZFuYpaBoG8=; b=YUToM6ix6/CVlyS8hSoqlafIwCxMDcao/qLZJVr8J7xQ3maLDV6UclZPvjnzWxa2nB5eOF 5LNZxdFQn53JQhcL/hwrBlNssj7y5zWLreGxLI6knHziKGF1UGd+0SSkv/ikePjMqtX1iO AjFXvyhaTz0f2C3ugbJyTrOpViZFXmg= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-227-oGkqZtNmMnyCC64mhThDxg-1; Wed, 01 Jun 2022 08:14:35 -0400 X-MC-Unique: oGkqZtNmMnyCC64mhThDxg-1 Received: by mail-wm1-f72.google.com with SMTP id r6-20020a05600c35c600b0039740f3d32dso3247121wmq.9 for ; Wed, 01 Jun 2022 05:14:35 -0700 (PDT) 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=lMUArCTwyhl0gL8o4f4vz4ehSKmCnNPpyZFuYpaBoG8=; b=W9P7DbzbPEfCh+3cdJIRSf9RbIh0YArI0zFRp8/FybND2Y/YoKqNtyLWF0u1J1x/mj vfxf9zWnf+twB5LFrQ8E6QyU4aTeatXO4faxotYOX5k+BxfocWFM26jz0y7pl00FaRCn ndaw/1xIXqZLraXZ0gRu1EZgPgJNcSydOpNh5paZ18c+XguNeu9phlQoxiKT8L1C9vUs l4kzqfT0wOPD1EOxVvYpzsLodv3Q8EqdCN6MngKyMy4qQOe3blemDIGGEZnCXrx9y7tz AnwGpFzu/wU594xMSFHZb4jtKCNTfTUmlJ5IyK+34xauZr3f+BaKAG2BUP/7tAZfX4Fp RKOQ== X-Gm-Message-State: AOAM53043N9YfYIyxFx/cmdcS0JToPDQPIV29VHQGTEpApV9i+DnqCZJ 8q4zr8pIlOuxSC3ZOFfTNooJXBsA4UiBolbce/3Q+4NoxrjvyMdKuH6U5lWKzNxtM7VvIg6uJ8Z jTSeuKrey0Tc= X-Received: by 2002:a05:600c:1e8e:b0:397:4770:11f5 with SMTP id be14-20020a05600c1e8e00b00397477011f5mr28209674wmb.50.1654085674660; Wed, 01 Jun 2022 05:14:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyhqUU94NDeO1uL+61amd12ri4k0yhNAHDglkrMQRXbMfaUDmR37msAZO48npN1A6qbfbHPDA== X-Received: by 2002:a05:600c:1e8e:b0:397:4770:11f5 with SMTP id be14-20020a05600c1e8e00b00397477011f5mr28209650wmb.50.1654085674330; Wed, 01 Jun 2022 05:14:34 -0700 (PDT) Received: from ?IPV6:2003:cb:c705:2600:951d:63df:c091:3b45? (p200300cbc7052600951d63dfc0913b45.dip0.t-ipconnect.de. [2003:cb:c705:2600:951d:63df:c091:3b45]) by smtp.gmail.com with ESMTPSA id y7-20020a5d4707000000b002103e9c1233sm1443172wrq.56.2022.06.01.05.14.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jun 2022 05:14:33 -0700 (PDT) Message-ID: <88604b32-d13c-40e2-3ef6-9defcec805cb@redhat.com> Date: Wed, 1 Jun 2022 14:14:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 To: Matthew Wilcox Cc: linux-mm@kvack.org References: <20220531150611.1303156-1-willy@infradead.org> <20220531150611.1303156-6-willy@infradead.org> <40d658da-6220-e05e-ba0b-d95c82f6bfb3@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH 5/6] slab: Allocate frozen pages In-Reply-To: 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 X-Stat-Signature: ecmfjmuxwb3nfwz4rwj4j1mk7ie6kqcq X-Rspam-User: Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YUToM6ix; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf24.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 104DA180050 X-HE-Tag: 1654085661-159251 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 31.05.22 19:33, Matthew Wilcox wrote: > On Tue, May 31, 2022 at 07:15:14PM +0200, David Hildenbrand wrote: >> On 31.05.22 17:06, Matthew Wilcox (Oracle) wrote: >>> Since slab does not use the page refcount, it can allocate and >>> free frozen pages, saving one atomic operation per free. >> >> I assume that implies that pages that are actually allocated *from* the >> buddy now have a refcount == 0. > > Yes. > >> IIRC, page isolation code (e.g., !page_ref_count check in >> has_unmovable_pages()) assumes that any page with a refcount of 0 is >> essentially either already free (buddy) or is on its way of getting >> freed (!buddy). > > That would be a bad assumption. We already freeze pages for things like > splitting, migration, and replacement with a THP. If the usage is just > an optimisation, then that's OK (and maybe the optimisation needs to be > tweaked to check PageSlab), but if the code depends on that being true, > it was already broken. Yes, it's an optimization to not go ahead and mess with the migratetype of pageblocks (especially, setting it MIGRATE_ISOLATE to later reset it to MIGRATE_MOVABLE) and so forth when it's obvious that there is unmovable data. However, freezing the refcount -- as used in existing code -- is only a temporary thing. And it's frequently used on movable pages. If migration froze the refcount, the page is most certainly movable. THPs should be movable, so it doesn't matter if we froze the refcount or not. Pages that we collapse into a THP should be mostly LRU pages and, therefore, movable. So the frozen refcount doesn't result in additional "false negatives" in e.g., has_unmovable_pages(), at least for these users. > > For this particular case, I think has_unmovable_pages() is only called > for ZONE_MOVEABLE and Slab never allocates from ZONE_MOVEABLE, so it's > not an issue? has_unmovable_pages() is primarily useful for ZONE_NORMAL. For ZONE_MOVABLE, we really only check if there are any boot time allocations (PageReserved()). For example, alloc_contig_range() implicitly calls has_unmovable_pages() when isolating pageblocks and ends up getting called on ZONE_NORMAL for example for runtime allocation of gigantic pages or via virtio-mem (nowadays even in pageblock granularity). Long story short, we should document accordingly what it actually means when we allocate without increasing the refcount, and that people should be careful with that. Regarding has_unmovable_pages() and frozen allocations, we might just be able to keep the existing detection unmodified by special-casing PageSlab() pages and detecting them as unmovable immediately. -- Thanks, David / dhildenb