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 038EDC3DA4A for ; Fri, 2 Aug 2024 10:02:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 74A1B6B007B; Fri, 2 Aug 2024 06:02:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F9E96B0083; Fri, 2 Aug 2024 06:02:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E8C26B0085; Fri, 2 Aug 2024 06:02:44 -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 4223D6B007B for ; Fri, 2 Aug 2024 06:02:44 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CEBDD81102 for ; Fri, 2 Aug 2024 10:02:43 +0000 (UTC) X-FDA: 82406866206.17.664AEBB Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf14.hostedemail.com (Postfix) with ESMTP id C9DEB100025 for ; Fri, 2 Aug 2024 10:02:40 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=none; spf=pass (imf14.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722592885; 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; bh=5hai+tNsyot5CbIlcAVmS6EL0sjO0mA2Kg3qIditQYs=; b=p5sqAjgfVCUoN1W1KGi5qwwYzd+NK+s/C7StGSl483eylbkZI2pt4USNJNI9gE35D4u3BX RxGiJFoOJXkvbcCxKN7DZqQgbCxdfEMy3lytdAdl1zDQELBRmMjqRHRrSe9MpwMOKZ5Ct1 joGc2yzvu9dpNbtZQtvL0ypB/l+No/s= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; spf=pass (imf14.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722592885; a=rsa-sha256; cv=none; b=w8RCOp30W1C9K8xQjOpc50FU12iMPZIbs+s0grjJ+YbUvBTN8+uD1G+wWiNHbW5kMhrmcC j6YSDZ0SyxoC4rdg9y0chZkI69HgnGGyxZeE6PHwF+30HXBuXFh5heESaaVhQ7qNRpB2wr WCuBaAm884X/mGCeTEmd+ckLWnAnsC0= Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Wb1YS6lzPzfZ8C; Fri, 2 Aug 2024 18:00:44 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 6560418005F; Fri, 2 Aug 2024 18:02:36 +0800 (CST) Received: from [10.67.120.129] (10.67.120.129) by dggpemf200006.china.huawei.com (7.185.36.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 2 Aug 2024 18:02:36 +0800 Message-ID: Date: Fri, 2 Aug 2024 18:02:35 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v12 01/14] mm: page_frag: add a test module for page_frag To: Alexander Duyck CC: , , , , , Andrew Morton , References: <20240731124505.2903877-1-linyunsheng@huawei.com> <20240731124505.2903877-2-linyunsheng@huawei.com> <03c555c5-a25d-434a-aed4-0f2f7aa65adf@huawei.com> Content-Language: en-US From: Yunsheng Lin In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.120.129] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemf200006.china.huawei.com (7.185.36.61) X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: C9DEB100025 X-Stat-Signature: 1rkmrnjburifnbx4xgyf4z58iw5w6uaf X-Rspam-User: X-HE-Tag: 1722592960-610459 X-HE-Meta: U2FsdGVkX19uGdrwSSVsCgG0uwXHLkd1XRoEbbZyaxNoaTx8/l5rmM7FQAQlFIG1WW7/3ojpoT8y6tHXyOI+NZFGwmiixNCZgP24To1jJ28w2NbGjlRfR0ncDezwnnmEmczTvl/EwQ2LvHKTVXYrPVf4p7meXNvvYXXvPcuLzN2laIcbf5yNz0BtzH1fMGouarJbo7sr7BlEkhtJ7QueoofKiU8A0odMvYFT1bRY+SYg4EAJRoX1Mx/0EabY4GlnyoT+35mFm7ImZToWuxfHejTJHnRaBqnciS7zRNz+SyqSc4fUsEThMoa5xqO7s0hkwWWb/T0eqLVS1IcWwGYSio3W0SAutwnuiA1ZSMCIgT62H3dsyUKfCjDCEKzWqSm9WLELWnZARRA3baUdWYL2Hj2NvEfbAc9/sWYN7oxDSnd0mY9vbprUu0sdhxXEBOKHOTC2F9sv9qe4cjkFy3mqeHBYpfedsDWcd0J4BN7DoFjsBgrjrbB6qMslFxk75WgFIP6H7VaFoSQTVmw4tS0XXiXYCbdtSsQQ4kG9HD5lCywHGLLN+Tw0fnW6jzJaaSNf1640Jjd9yHzuIqQ0xdZuwEevKbZ85Kq07QCndNtLSflojIGiFQih1XryojN84tyGa7Z4jy0Y26l7dZeXhcQAG5/bSPEfw0bE3tsZMmeW1Khq91qcKiMi5tVx046cvC9mNlkXoarnfsb4AcORZ5HTA6275LlPPSEGpLUqwqDNlN0xPV8b0po2QsEHFH3p9u16nX2fM/joN9qGpvqsjJcP9jC8ERusGAdVdcZjzRTriznoXFjCgMoZk1hCaNGLMpcMWGyCwnvmO3tRH5te9fnkAs0+EDdG42Mx/phzhuvbICYLLbrEzXh8rLk69gB2GpA9zTP48OvowmpJAkFteE8mQUIoUakPYaD+cZGtJ8Xxrk3BLu4cbN2SlTFPRf+tiBJNltn63g8ymd1jO0otjWF XFl4yCc/ 2AhZSdJRlfZpMEHTq6yY0YROxbCi3AnBdyjAvkKv5ykwRDkYO16bO1Fvv+jE5D8pp5lnyXx5DErBPMu/xRHSMQHctStxP5dT81Qrbj4rIrqOi5OVcEwxMM7sGsFYlrDqRXa3bRF9eWuIXSCJ6dvkx05qbgdz1psC5eR52CAoTGhCDgLMQEz/t6roV3ox+ufs1sFK/9JbzVusqPfZRrFApXeBFYeNoCsTlFeORHWNSbpvOWe6UdLmn6ESAQuxZMxpwWEnFtKLsnSbO8VXYL5JvYTs4IZJnDsamcqut 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 2024/8/1 22:50, Alexander Duyck wrote: >> >> The above was my initial thinking too, I went to the ptrpool thing using >> at least two CPUs as the below reason: >> 1. Test the concurrent calling between allocing and freeing more throughly, >> for example, page->_refcount concurrent handling, cache draining and >> cache reusing code path will be tested more throughly. >> 2. Test the performance impact of cache bouncing between different CPUs. >> >> I am not sure if there is a more lightweight implementation than ptrpool >> 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. > >> >>> >>> 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. > >>> trying to force it into the mm tree. The example of dmapool_test makes >>> 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. > >>> 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 testing >> 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=16 test_pop_cpu=17 > 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 guess it is ok to return -EAGAIN?