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 5025EC3DA4A for ; Fri, 2 Aug 2024 16:43:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD9E36B0092; Fri, 2 Aug 2024 12:43:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B88816B0093; Fri, 2 Aug 2024 12:43:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A4FB86B0095; Fri, 2 Aug 2024 12:43:27 -0400 (EDT) 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 884226B0092 for ; Fri, 2 Aug 2024 12:43:27 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 17010141372 for ; Fri, 2 Aug 2024 16:43:27 +0000 (UTC) X-FDA: 82407876054.22.0AC71DF Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) by imf20.hostedemail.com (Postfix) with ESMTP id 2953D1C0029 for ; Fri, 2 Aug 2024 16:43:24 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CYZ2ZuTA; spf=pass (imf20.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.221.41 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722616946; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GfTIzAiAF3r0Bgvrue30RkaKI+Y4QRU9lsEkdGPK3oE=; b=PaUfte208wkMTxzIpe9saeF2bsEsz3MFPvevVnKcP1ndQYB8CVVtkrvgDTvhisuocLi/WZ Q8umaj1QY86dauoGrXfRjYpTF8SsPm0HNiAdMrurdgillFj5stk2I8jIymyrpnUkh+LAip ILjanNt8HIdmi0H7NEzHbtqaw+mIT4A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722616946; a=rsa-sha256; cv=none; b=mPvgTgSCCnCHW4o7Q3qD2NK0E0BlfTX5cYQo852Skc9eUrwERfHJqLorD22rbn5bWzCeug N0Z6+51vs97mqE9DWvES0gRhbDvrE1kkwniT0APvtI1ExAAJEEEkyHUIsjdmKkXBxm25KV 6OUy6XCgfuPe3Ib21677aMxZoeQKzoU= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CYZ2ZuTA; spf=pass (imf20.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.221.41 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-368712acb8dso3949398f8f.2 for ; Fri, 02 Aug 2024 09:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722617004; x=1723221804; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=GfTIzAiAF3r0Bgvrue30RkaKI+Y4QRU9lsEkdGPK3oE=; b=CYZ2ZuTAhgO7NsPru3MbGUxowzN7v5/J+BQdBe3mgxhNM2iNmEsYrSnDWHUU7zKoyI mqcgwbzBgGY4dCP2w50xMVajf/szsK5nytOfOBJuD1bxfixGTm+ySWJHq4H8D98Fiq7F PnD/C+o/+3hRi4tY6URH+5WRA+HjrecQ1TacgQ2MoW77w3k+mY5s5OnN2mb0eng+dQI0 NWT3HkAjLJrbsUPM2lEjrSq2JAJ0SbeNH8sejkeZuFAl0cuGDbxQ8fvfEw0Rzw3D5V1S NWNNpgsKCZTVQPrLt3wsA8tgRpN2Y2M+a7b+lH66/7CcyY321LFRfBO9uJsW9lCQvNZ/ an/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722617004; x=1723221804; h=content-transfer-encoding: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=GfTIzAiAF3r0Bgvrue30RkaKI+Y4QRU9lsEkdGPK3oE=; b=uP6AEDONRUEC4CzSoHNXmHB9KClidy0+IB20MdMItlCLfzAkiU+zUTJgb7vPBwLLHF X246wMW2QsKS9ORZDzgsKTvxikOSiDd89/uIEcuRvmAovO2B2RBwi2a62JP/tP7X13c/ JrDgLr1/Y0kfSLUNjAn7z6v1u3Yhr9krwcCD+DRErMMELGEO+pGH2dOWfh4XxDnbeZdY UkQ74YexSSh6pw5rmX1KIl18+oARI4KxtNdSY2lC+iL1nQ2U8O3fchRyvKOhGHhT8buz i+fFxyPYuk0YHHUGCICoEpYmdJiS7sy25VdbdGrwXO6i41MSB7QsZSe86h9A+veXCuYV urMw== X-Forwarded-Encrypted: i=1; AJvYcCWtHlAxVPwW645gwb6tk71LfBaOT2zr5SzWULSTptOB1dxkLHzKQ1+prK5TgbkOh7KjGIDyCX3I/ePhAFEOfJu8hY4= X-Gm-Message-State: AOJu0YyMLVSjJV6rocQGf7lqGlpxvJOoRVh/RFSVeShHeENT5YYhtdVp R4rjiiuc0wy77yblwKjEjEnRPsvpJQPRkIyyjQVY38W02d19PuLqYBtMSTjXTv0eQteGPjoLOz3 62m6uUYrbMOqoKaxbpaf9/sUEGYU= X-Google-Smtp-Source: AGHT+IE1qaX/xzlkjD1NORh6HKCoaKH3HHSqkYZBx282lGLK+nCdSMJHna0HItXyLdgbxyMssFFqz3Fk8OyHhkRb4qY= X-Received: by 2002:a5d:6281:0:b0:368:3f60:8725 with SMTP id ffacd0b85a97d-36bbc162fd2mr2621001f8f.39.1722617003435; Fri, 02 Aug 2024 09:43:23 -0700 (PDT) MIME-Version: 1.0 References: <20240731124505.2903877-1-linyunsheng@huawei.com> <20240731124505.2903877-2-linyunsheng@huawei.com> <03c555c5-a25d-434a-aed4-0f2f7aa65adf@huawei.com> In-Reply-To: From: Alexander Duyck Date: Fri, 2 Aug 2024 09:42:46 -0700 Message-ID: Subject: Re: [PATCH net-next v12 01/14] mm: page_frag: add a test module for page_frag To: Yunsheng Lin Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: zhofujexmub9s8nrmrwk1qajyk5x3rkp X-Rspamd-Queue-Id: 2953D1C0029 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1722617004-455224 X-HE-Meta: U2FsdGVkX1/TunB89XQMDVxC0IKZcjkQ1gjNLLm/vfBa/GzLe4SvpbAGPVDpdkTCT7KQT+k9xJUfSgifJtmwtCtNxyH0WjZL/sm95Kq4GJdS1CiBIOcMhUZm8I6gVlGf9O3zeZX0bStUhzcTdCtqeq7ksdNK3Nv+HZWBJdeh6uGayxb7nsyfHtu9zFtegGMqEeByHV5qO0LdOuUIgeU1NOZXLeSNviaKOMGXaLv4UPcsUEVCjB1qK3bhvpK5Q7aBsUMR3VXRyWIhv6C1rHg0w9JlFlZKJV4VPfH03zEr6w9b0tDaFYiwR9GESsaXKvdSAxMVRmKKxQrf015VQXmkM+JWKjIS5lFrDluGKL2cxCpuzyI1NRfOQ67ekQ5WYT8kuPPUQUuAjOfWemv7XGW/OMniPtQ4ouck+U8MkGb15HaFzHVkS6eZK7aNj8OPnNPs+HXnF1NMSbVjtbeuNxGanDNYl/Q3N+/ZSTROvkQLDUkROvIjddlige+gxhKJuWg+qi2ZlKkuBNLMybpIxIF8qINH4sSlvV3BwfnfmhebmaxcVLbxS0FJd4G7HJVee6oa/RIKNlvRG0NGAUI5oczlFKx1G/fpnClQll5MXDU503E4YKM4KlnkM0pUSYOi6o5odMux647pjxsrXtBjNE9GQ6EjtKTEuYRa4hANirZGYU5ZTJLwK2Tvjwn3bSzbRDd1cqWpl4hEI+TQVTnf1FHSKcO58SvXHpDPOUnQBdkx1ISoyYG6nfDUtBUTjCDv2FdhcNcBThDTOc7Y+kdFyKni/jW98QNpRLrA/jyqdxU1reKfITu31ftLUxZI3M1uR0zVZEi/hNe1bs7RvpzZ2tuPf1XT08dX9oq6dDIpRdYczWWiCIUeRuJR8voUB1lOjhl+HrLy2Y0e7KYn/e+qPYyDB2YT1PzK5+Y/ScW4/f1hEYSP3BmX/lkaJRbfg0bWNOGCOS+2c6V1D/6jkNNVTJK Flwm2+Zt 1OFJEulOP009AiEdbknpUe1o5B9ujS8RhatN26up57kNKGwdVfXOPyVwBEkjqmA8CAnwGo28nPUJoPCT4rN8MatEyYmVhddTVitffGbjJ/kMEWFDf7sjLOKtOwtwktfy+HDpVFKKgPD7NetCHMbMYu9c7T+PI9UE8b2aGGB0f6e69qUiwYsEwP1NOwdwoiqUnsIm1YOR9lm639xAFT5ubMqc3KjN3VYb2EDMftSDHEDZzSDLAnvUzJhXg8z/JN97Hoym0cejsqxJJaOACxMTsBkFAj/BFE6H+/XERmbMiNBZwgHbWVwxKMArx75hFh6Y68ykLToI/fZIKCaIzHqyZVdBcdY2Ek0K/6K7WvPeg86mZORGo127GS0rkYa/0YCCWtobDVejGMfnbdYg= 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 Fri, Aug 2, 2024 at 3:02=E2=80=AFAM Yunsheng Lin wrote: > > On 2024/8/1 22:50, Alexander Duyck wrote: > > >> > >> The above was my initial thinking too, I went to the ptrpool thing usi= ng > >> at least two CPUs as the below reason: > >> 1. Test the concurrent calling between allocing and freeing more throu= ghly, > >> for example, page->_refcount concurrent handling, cache draining an= d > >> cache reusing code path will be tested more throughly. > >> 2. Test the performance impact of cache bouncing between different CPU= s. > >> > >> I am not sure if there is a more lightweight implementation than ptrpo= ol > >> to do the above testing more throughly. > > > > You can still do that with a single producer single consumer ring > > buffer/array and not have to introduce a ton of extra overhead for > > some push/pop approach. There are a number of different > > implementations for such things throughout the kernel. > > if we limit that to single producer single consumer, it seems we can > use ptr_ring to replace ptrpool. Right. That is more or less what I was thinking. > > > >> > >>> > >>> Lastly something that is a module only tester that always fails to > >>> probe doesn't sound like it really makes sense as a standard kernel > >> > >> I had the same feeling as you, but when doing testing, it seems > >> convenient enough to do a 'insmod xxx.ko' for testing without a > >> 'rmmod xxx.ko' > > > > It means this isn't a viable module though. If it supports insmod to > > trigger your tests you should let it succeed, and then do a rmmod to > > remove it afterwards. Otherwise it is a test module and belongs in the > > selftest block. > > > >>> module. I still think it would make more sense to move it to the > >>> selftests tree and just have it build there as a module instead of > >> > >> I failed to find one example of test kernel module that is in the > >> selftests tree yet. If it does make sense, please provide an example > >> here, and I am willing to follow the pattern if there is one. > > > > You must not have been looking very hard. A quick grep for > > "module_init" in the selftest folder comes up with > > "tools/testing/selftests/bpf/bpf_testmod/" containing an example of a > > module built in the selftests folder. > > After close look, it seems it will be treated as third party module when > adding a kernel module in tools/testing/selftests as there seems to be no > config for it in Kconfig file and can only be compiled as a module not as > built-in. Right now you can't compile it as built-in anyway and you were returning EAGAIN. If you are going that route then it makes more sense to compile it outside of the mm tree since it isn't a valid module in the first place. > > > >>> trying to force it into the mm tree. The example of dmapool_test make= s > >>> sense as it could be run at early boot to run the test and then it > >> > >> I suppose you meant dmapool is built-in to the kernel and run at early > >> boot? I am not sure what is the point of built-in for dmapool, as it > >> only do one-time testing, and built-in for dmapool only waste some > >> memory when testing is done. > > > > There are cases where one might want to test on a system w/o console > > access such as an embedded system, or in the case of an environment > > where people run without an initrd at all. > > I think moving it to tools/testing/selftests may defeat the above purpose= . That is why I am suggesting either fix the module so that it can be compiled in, or move it to selftest. The current module is not a valid one and doesn't belong here in its current form. > > > >>> just goes quiet. This module won't load and will always just return > >>> -EAGAIN which doesn't sound like a valid kernel module to me. > >> > >> As above, it seems convenient enough to do a 'insmod xxx.ko' for testi= ng > >> without a 'rmmod xxx.ko'. > > > > It is, but it isn't. The problem is it creates a bunch of ugliness in > > Yes, it seems a bit ugly, but it supports the below perf cmd, I really > would like to support the below case as it is very convenient. > > perf stat -r 200 -- insmod ./page_frag_test.ko test_push_cpu=3D16 test_po= p_cpu=3D17 That is fine. If that is the case then it should be in the selftest folder. > > the build as you are a tristate that isn't a tristate as you are only > > building it if it is set to "m". There isn't anything like that > > currently in the mm tree. > > After moving page_frag_test to selftest, it is only bulit as module, I gu= ess > it is ok to return -EAGAIN? Yes, I would be fine with it in that case.