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 43309C021B8 for ; Wed, 26 Feb 2025 12:21:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C913B280015; Wed, 26 Feb 2025 07:21:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C40EF280001; Wed, 26 Feb 2025 07:21:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AE113280015; Wed, 26 Feb 2025 07:21:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9008E280001 for ; Wed, 26 Feb 2025 07:21:54 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2A92E5342D for ; Wed, 26 Feb 2025 12:21:54 +0000 (UTC) X-FDA: 83162007348.20.4246426 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by imf24.hostedemail.com (Postfix) with ESMTP id 0D0B418000F for ; Wed, 26 Feb 2025 12:21:51 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=BYQYriyl; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of jackmanb@google.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=jackmanb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740572512; a=rsa-sha256; cv=none; b=yCt3tR7zJLPU2+Pf3CWV+wKIYSOZQIBcQrv+yffe6fQpHzyr3hjiCGvlYV0YTbuVZY5EZY RN/RMt6Na62C+cG8kIzV8OcR3XeCRrNyYnbz6L8QE0u3JCwrOprQRWiDZ3FZRq2zESealQ bwn9Irxq5o6hxx4YJw89Rf2knMharPo= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=BYQYriyl; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of jackmanb@google.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=jackmanb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740572512; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FZ8fLnFs5jC511KEwwc78QvRtxNOftae4m622VwEotA=; b=GOitqMniW2X9w+yfliPk5WlVfFjIAHl/bZKCeCK5hkXIFJdJW4UHa9D8AODnNS87wZikQW YTKWyVqaGtlY5z/pNeJCptKjq2j87nMvmSgFVF4t6A4XVdy2qxUGWTBwDH4pm5X7P5Auj/ v4tV4gWvtVDq9S3u24bM+qq9ZHSi8l0= Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-471fa3b19bcso226421cf.0 for ; Wed, 26 Feb 2025 04:21:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740572511; x=1741177311; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FZ8fLnFs5jC511KEwwc78QvRtxNOftae4m622VwEotA=; b=BYQYriylXiDz8NFNdY9WlN36+FEAsqUlJ/Y+3gvLBss7j6Y8Wn9IXECsgnF5c9got/ Asx4/FncyhWx24k6UBfbW+QU7+9+Fri7AkqsX7Xuogi+hKgN7QOK8vwJnQdApau4Vkax /j+bu4Palz9gMuMu8O8PODo5l1UU3BFAoKUJSrCi+XUNtRrL8wFpK/gUiqs0XeyVvdk6 ZcmE+6R2+m7VJLAVL6aCCZlMsma1yjzFfZ/vFrqF6Uzw/iplXA4/LCci57cPUOEI0StI gtX8LNPdeKz/5y60z6zEVfQwSp7sk0XpkEVZ8gvUB+Vyjzsgxyqwkh9jnS1SoFTmBEMk /tBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740572511; x=1741177311; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FZ8fLnFs5jC511KEwwc78QvRtxNOftae4m622VwEotA=; b=q8ugwvMqX4bry2MfRwpu1HKKSoPi+oaTH4779ohl0tUm7cKb3aFV9gNVjQYlapveAF 9Sn0LcJj7jFp2MT8FIIUSEOJgqAkTVVmQatuWZhhTM8SKyKVegxNcpxIQ0OsuZ9SUKRj ZL19jM+ZVetX2ddVW4At/00RmZNYsin++tryDHZRRURKhjFD70coqAvo4xNL5r1n/3DT uoqcuJGFfw9hk6O3Xx2YfNTb0KYcjJXR+FEp50mrbhiO06rGOQF1JZpx5z1iA/hnNDkP JSvTVXWi5n712YhON3n5RdTie28To415+9joM2rL3vqjV3yDsyfFNxAwLR8fh/lJ0P0G IQ4w== X-Forwarded-Encrypted: i=1; AJvYcCVIUjMRH4nlRPbg37lWbrhsZpOyExP0SU6AKc3k5UE1IfRWxUmdXORz5T4Fj/1yP99NCyMYjgLIwA==@kvack.org X-Gm-Message-State: AOJu0YzuaVlwkcy/MakUF1lP2OsrYNfNb9EkB7VK157fOAV4lI3U8gOC i13/Ci21FkUCBQDJ3hod+xaNZNfNdb42rQfW/b1OFgd2yxS5H6jR8R7+/qu4npFns+4UaUIyCZD pCwEA21A+M8fXEuefB+DNmyxsUtJOr8bexrDV X-Gm-Gg: ASbGnctQSo6tjsvyZpXFyCUT1oAfZMimReW6iM0H83K9ds46TsEpsKXlOrUwBUIpYzX Ll/TRrKVqnOzEceN8wv4reWo0oq9vRF/msp23fsGTxIp4XX4SA+SI2Vr/VUVQ1oUFJrZnhnh99K GILIvIgN8VxmQW3h3BEQMYSpevb+YJj6d4HoU= X-Google-Smtp-Source: AGHT+IHhkPpVrAfcuu6cQ99DaZetDklozQpTm2/0R7nz9+TlVkUIb9LVAMa4c37TFqY7rDF6/NSPiYVd6iEl3BowJcw= X-Received: by 2002:a05:622a:1806:b0:46e:1311:5920 with SMTP id d75a77b69052e-47376dd1d49mr8958801cf.0.1740572510952; Wed, 26 Feb 2025 04:21:50 -0800 (PST) MIME-Version: 1.0 References: <20250224-page-alloc-kunit-v1-0-d337bb440889@google.com> <0449ff75-0a6b-4c1e-bf12-ff052aad5287@redhat.com> <657f10ed-4e82-4048-98ab-1c4b65349298@redhat.com> In-Reply-To: <657f10ed-4e82-4048-98ab-1c4b65349298@redhat.com> From: Brendan Jackman Date: Wed, 26 Feb 2025 13:21:39 +0100 X-Gm-Features: AQ5f1JpRBblxfE48EKs85Q8pbMMgiuSClFK4hMJuxnVUG4HT_JiUqeb3ib6VHjM Message-ID: Subject: Re: [PATCH RFC 0/4] mm: KUnit tests for the page allocator To: David Hildenbrand Cc: Brendan Higgins , David Gow , Rae Moar , Andrew Morton , Oscar Salvador , Lorenzo Stoakes , Vlastimil Babka , Michal Hocko , linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Yosry Ahmed Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: 0D0B418000F X-Rspamd-Server: rspam12 X-Stat-Signature: 8xda4r59pci983qrm3yqy8p8uh5zacdk X-HE-Tag: 1740572511-318791 X-HE-Meta: U2FsdGVkX1+s0gedf7Y4N+zvvO13ORvh9vYRf+a8/pOjq7aY+q4j3nE5RBSiMNLL9392aQzaRuQwHGgCVz7McMgBbqKTao9PrfnC3Rm1Ubclf7cYeQpxVhRHKqiuu4mEWzI5ZX2OMspA3OuJqU5EDZ8K7M/kKADvPOz750bh6LZ4VxG0VAbBXFE7akD0FEMqyFYhqRXJHJbf/484961FgCG7Jdu1FKpa42FTpDbiIV5vHcYbsBaDR7jgJXyvG2lCM2gEhY3CYUCNQ2qIKzi/etiagvRSclhOo5ME856d4rQB9nblYH0+BKjZDyNk0rBeFKcHGXDW1daXGx4+OguRGYJdTTVbePXLpQOxr5JIoTVgAtwgYd/m2MK2PeNuEByjiNM27+1z2slMAUOJ1CMI0kHJ1oe2sa+liR8BulEycZ8kfsXZZqzGkG0kpShGpsI73Iw0mZX/t8dDcEZhBBviZEer35CLjlANNaa+B9iGKTPf6k3aaNtvA9T/e0TGVr73KrTOI9cPsd1IoEO+8qL5JjqYeliWSsAQA+vAz2yaxvKwKzfA9pbLT4uNMRsenI8W1fi52RUxAwlCc4CZk5zl9AjsM8QSrjnCtSjPALIPQyAEMexINWT3pp4R0t/T3Kvf/Lahgj5uuiziCg8qWhp36PMnkZdzpjjdWD6pjIKJ591Sq4czp+yo8KsxFIn6ZqZO1qMw7KYM72vP+fKZ0mTt2GUaGglKFAd15Jz9VG9JKOSu2sg77i/npt1ewcIf7YWJxIEVn3PbOY1bjbYmDHd9XrB6ala/nRlAL9w1poIEr0HBF7pDksvnZB7hjDTjt34b9LsjWd6spQ+4icFexc8d5Bel8iIJUxM9abDTaV6RFGL/I6jQGFBnqijzBDgmJWJxM/vjczdZu7b8WRQNi0NYdMv+hBcdXBD26cOkNlbtrPPS2/fN6qgnKkvsmSRGcYwxrgDhfvahA26n4c3bTBl tf1apagE rwx3OGZPwnUk9+8RlmYwcl0xBLWK2QzH/L8/jr05ez4/v9TewNm4CFB4ykDfZ2bAIJ5GK1k8mCv0EfjEic2lpRUa2MZ0AF0Xph0lslBKCo54QOcNRdsUD/gdX7bM1p4goT8p55zp4RDmgfbJ2FmmfynJ8yHVZGSk/Oo2fcBBo/ct85rOg1ZjbhqOa6fjcrfYR+2ADzK7HDba7M64Gr0XciCtzggkfvS3QgdT6 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: List-Subscribe: List-Unsubscribe: On Wed, 26 Feb 2025 at 12:52, David Hildenbrand wrote: > > > It seems possible that very little mm code cares if the memory we're > > managing actually exists. (For ASI code we did briefly experiment with > > tracking information about free pages in the page itself, but it's > > pretty sketchy and the presence of debug_pagealloc makes me think > > nobody does it today). > > At least when it comes to the buddy, only page zeroing+poisoning should > access actual page content. > > So making up memory might actually work in quite some setups, assuming > that it will never get allocated. > > The "complicated" thing is still that we are trying to test parts of the > buddy in a well-controlled way while other kernel infrastructure is > using the buddy in rather uncontrolled ways. Thanks, yeah that makes sense, and I agree that's the hard part. If we can design a way to actually test the interface in an isolated way, where we get the "memory" that we use to do that is kinda secondary and can be changed later. > > There might be arch-specific issues there, but for unit tests it > > seems OK if they don't work on every ISA. > > Just pointing it out: for memblock tests (tools/testing/memblock/) we > actually compile memblock.c to be used in a user space application, > stubbing all external function calls etc such that we get the basics > running. > > It'd probably be quite some work to get page_alloc.c into a similar > shape, likely we'd have to move a lot of unrelated-for-the tests stuff, > and think about how to handle some nasty details like pcp etc. Just > wondering, did you think about that option as well? > > The nice thing about such an approach is that we can test the allcator > without any possible side effects from the running system. Yeah Lorenzo also pointed me to tools/testing/vma and I am pretty sold that it's a better approach than KUnit where it's possible. But, I'm doubtful about using it for page_alloc. I think it could definitely be a good idea for the really core buddy logic (like rmqueue_buddy() and below), where I'm sure we could stub out stuff like percpu_* and locking and have the tests still be meaningful. But I'm not sure that really low-level code is calling out for more testing. Whereas I suspect if you zoom out even just to the level of __alloc_frozen_pages_noprof(), it starts to get a bit impractical already. And that's where I really wanna get coverage. Anyway, I'm thinking the next step here is to explore how to get away from the node_isolated() stuff in this RFC, so I'll keep that idea in mind and try to get a feel for whether it looks possible.