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 54DF4C3DA63 for ; Wed, 24 Jul 2024 19:48:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA6626B0083; Wed, 24 Jul 2024 15:48:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B56136B0088; Wed, 24 Jul 2024 15:48:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A44E26B0089; Wed, 24 Jul 2024 15:48:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 865976B0083 for ; Wed, 24 Jul 2024 15:48:43 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D38A91A03BE for ; Wed, 24 Jul 2024 19:48:42 +0000 (UTC) X-FDA: 82375683684.05.6AB9B30 Received: from lobo.ruivo.org (lobo.ruivo.org [173.14.175.98]) by imf23.hostedemail.com (Postfix) with ESMTP id EFEBB140012 for ; Wed, 24 Jul 2024 19:48:40 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of aris@ruivo.org designates 173.14.175.98 as permitted sender) smtp.mailfrom=aris@ruivo.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721850473; 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; bh=+htlhs8vLMT1QfKWVlHSatr53IFO991fnE2h+yJuClg=; b=R5DDaXYHl56bHpD01Uc5TWcxyEVrN7bYObLJzU2X2fI8JXHZBJqVoOC/aNHNav6x92DnD4 1vGfjfzM/bHcFCajqScpuBWTfbCRbEK3UPelL4/48nF6bTPH+zBqDfmhSEpc907Ruykb0Z x2BRF+TbhBVRqa9/Dh0JQnOeVmEyKbI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721850473; a=rsa-sha256; cv=none; b=2+doCgRyZCvKehyKP6j2KIiKF9t1iTbXSc7yxrmP6ag8Vf+t46LFJWhOOu5jCeJvwdSR/L +Ebg69fQYD1ks1yfvWVXcUHfcfNO+hCA6fjJUnnHD6tVp2KNGjpPpD436EysyW1ZTAS1lI oGFFYmf7ZyzRNWhCdkC3OOCBCeuYaO8= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of aris@ruivo.org designates 173.14.175.98 as permitted sender) smtp.mailfrom=aris@ruivo.org; dmarc=none Received: by lobo.ruivo.org (Postfix, from userid 1011) id A8DF752AFA; Wed, 24 Jul 2024 15:48:36 -0400 (EDT) Received: from jake.ruivo.org (bob.qemu.ruivo [192.168.72.19]) by lobo.ruivo.org (Postfix) with ESMTPSA id 6D8DB5325A; Wed, 24 Jul 2024 15:48:34 -0400 (EDT) Received: by jake.ruivo.org (Postfix, from userid 1000) id 5CD4E120BB1; Wed, 24 Jul 2024 15:48:34 -0400 (EDT) Date: Wed, 24 Jul 2024 15:48:34 -0400 From: Aristeu Rozanski To: kernel test robot Cc: Aristeu Rozanski , oe-lkp@lists.linux.dev, lkp@intel.com, Linux Memory Management List , Andrew Morton , Muchun Song , David Hildenbrand , Vishal Moola Subject: Re: [linux-next:master] [hugetlb] 003af997c8: libhugetlbfs-test.32/64bit.counters_sh.fail Message-ID: <20240724194834.GM844599@cathedrallabs.org> References: <202407162105.5eab5c8f-oliver.sang@intel.com> <20240716154427.GI844599@cathedrallabs.org> <20240717204507.GJ844599@cathedrallabs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240717204507.GJ844599@cathedrallabs.org> User-Agent: Mutt/2.2.12 (2023-09-09) X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: EFEBB140012 X-Stat-Signature: podw9brekddk1qooebw5arxhwh91myu8 X-HE-Tag: 1721850520-869023 X-HE-Meta: U2FsdGVkX18bfdTatWMxVvW7+OQONJ6X74zhQTC/yVzNXPKFUIyEmLUCKc9dbVdfS+wP9LsvNxB/MJuRZtlw2q3Ul6vQfaDwwG/A21QZ2q4134kku0mOcswb/N59qMrITNxIdoTdsAVrbNqxrliy3fn2CHn2UjjwJ8Le5uJM3TdZElBzGUZ1e3FmqrdhNIF1ssEcoNYtUBD7YBxys4op9uzs8rzqHAKNWZWBBlekhKpsWGbJs7ZkJFqDsJgkAy+vbAovHEflNYjNQFoWikqR8v7NIu4kzedD7DmV4GYEPw6GYiLFB1Z/eSXvSELCjJGY/0BFz546g2St1cIYLVWs87nzq88GBL5N+qZk/4vsUsB2Bl9aUF1exBITXAKSAqq8y0OLsN0pVt3RM+762Gq3pQxbizJjWVxC/L1ChYrWBGNXujPwDwxPG3ruxhuJDcnwcfR8HrXzmKC2cB5/YWe2cHTA2LEfZfvWemnsbwUaoWH1QUtcmNJING1MMWRzaQUraTMI9u3VQep6RlpuT/ast0pLjR+csn/yTU8fFl8Uj8wuVVQr0MiVULuoZDsWBk/H0a+txqNa4Xnm7TlJliVQPyvFi1htvWfeWbHhvSqYgk6qmnCmFRfmHSIcKNW7Pf5erY9L4Q4GKxvcYMNnhtf0TJkoutYCEmGggFbf63jw4zxrQUuNor4IsklxB4rhuHN0+3/S209CsjrmnYwm0cxweBW8q9QN12ECXk+XEizMfYrv8HXGm42pVs6MVf72cneUEbPSDXdjmGSAuZjFVnQLaDhYA5Lexkb/9KZpeXWRn5JG+oXh3YYFB+7zw6nPI87oDUkCQXLqz2+q0vXx/hfK6KIAEc8/tEaB+HzwY+4HKJz2JIU4FE3MxVNCKzkYwEmJMVJLxmsjMVRz+7j2o3Lnb/QANsxRRpKfN2IqB3fOpMrRGrpPjE4PbGZ4g3DsLJlE8Igq23oqtfRnBpDQxtf C6ULJ2hB VCkGmgyjtoMIBQ7rCTthdzbXN6ODhrvNQ+Zt7ri1PeGm7NDz2LXuGWfMrKQHYLIF1yN6ETA7NBysjOImaFYvUXHI62BTNDt7pMafAxFBxrrocDM9BOmI+A7qyicBht8IQt/XpceBEwjvUj1EnW3eOL3RG0zg3PiX2rg9I 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, Jul 17, 2024 at 04:45:07PM -0400, Aristeu Rozanski wrote: > On Tue, Jul 16, 2024 at 11:44:27AM -0400, Aristeu Rozanski wrote: > > Taking a look on this. > > So it looks like to be a timing issue. While spreading some code to figure out > exactly which exact sequence is causing the issue, it makes the error go away > in the 'counters' test. More specifically one of the sequences: > > /* touched, shared mmap */ > map(SL_TEST, 1, MAP_SHARED); > touch(SL_TEST, 1, MAP_SHARED); > unmap(SL_TEST, 1, MAP_SHARED); > > fails because it's expecting: > > HugePages_{Total,Free} = 1 > HugePages_Surp = 0 > > but gets: > > HugePages_{Total,Free} = 2 > HugePages_Surp = 1 > > which seems caused by a surplus page taking too long to be freed, thus > timing making difference here. > > I'm not sure as why it'd take longer with my patch applied but will keep > digging. It really seems to be a matter of small timing difference. Even poking with perf is enough to not be able to reproduce the problem anymore. Will get in contact with the libhugetlbfs folks, might need to implement on the counters test intelligence to when there're surplus pages around wait for a little bit to give a chance for it to be freed. I believe we're good to go. Comments? -- Aristeu