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 3E67DC38142 for ; Wed, 1 Feb 2023 07:47:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B78E26B0071; Wed, 1 Feb 2023 02:47:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B29366B0072; Wed, 1 Feb 2023 02:47:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A18806B0074; Wed, 1 Feb 2023 02:47:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 90C836B0071 for ; Wed, 1 Feb 2023 02:47:07 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 58B8A806D5 for ; Wed, 1 Feb 2023 07:47:07 +0000 (UTC) X-FDA: 80417942094.07.11A77E8 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf12.hostedemail.com (Postfix) with ESMTP id 57A764001E for ; Wed, 1 Feb 2023 07:47:05 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=q+FgXzsq; spf=pass (imf12.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675237625; a=rsa-sha256; cv=none; b=42Wg3Xn8PbDhTWEDOgnPvD41NOLdRucKLscEqSwzrMG5CWxYVMWquEDWGQ3vuDKeGCRDAO sB2bBDBqOBRIjAk9IKsqvS0iuu+x8HKFaHh1nM1r4gKgNxTz+Ve3rV8r8m9oulRmebjh2K YgmLvoM8WN7GcQ0X5tpr0faIKFMnhkA= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=q+FgXzsq; spf=pass (imf12.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675237625; 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=Rag4+FVyQt+kbt+JWKoNP9ZXlNOyifoM2qoNM7/cbKQ=; b=yW4AnNQ7lnibudCVEZgq+k0bYxLwZzK39CQXG8QhutLdg5py6jxr19LYNgLV5rNZEpR3ep HuDXz6azLj4q2LUCplsu0lM6pcli8nMUJGFMo2pItZ8rwRIjGL8wmbqzLLEOETCvHuUWVq MsqNeJAN+GGwp3UCUeV5X2kBjmK3YV4= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 1FAD033A60; Wed, 1 Feb 2023 07:47:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1675237624; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Rag4+FVyQt+kbt+JWKoNP9ZXlNOyifoM2qoNM7/cbKQ=; b=q+FgXzsqSM00LgMQan9vaaEXqlLYtc39atFGGec47oO/dep2GxG3uC3mt7DIHUTOIWdkw1 FBrp/4LCISKSJ02+H7YKRpfIvcf3KzxQiwGCfVbQ8p4KdAsm7hDwvAhChgReGXdUymbUjC ALBLw81YylNVAYiWf8uNsUSUkNUatjg= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id F21511348C; Wed, 1 Feb 2023 07:47:03 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id jMbZOPcY2mP8NAAAMHmgww (envelope-from ); Wed, 01 Feb 2023 07:47:03 +0000 Date: Wed, 1 Feb 2023 08:47:03 +0100 From: Michal Hocko To: Mike Kravetz Cc: Andrew Morton , David Hildenbrand , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Naoya Horiguchi , James Houghton , Peter Xu , Yang Shi , Vishal Moola , Matthew Wilcox , Muchun Song , stable@vger.kernel.org Subject: Re: [PATCH 1/2] mm: hugetlb: proc: check for hugetlb shared PMD in /proc/PID/smaps Message-ID: References: <20230126222721.222195-1-mike.kravetz@oracle.com> <20230126222721.222195-2-mike.kravetz@oracle.com> <4ad5163f-5368-0bd8-de9b-1400a7a653ed@redhat.com> <20230127150411.7c3b7b99fa4884a6af0b9351@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: 57A764001E X-Rspamd-Server: rspam01 X-Stat-Signature: n7hxisohq4rex9tm7xziqfw65nrqd3an X-HE-Tag: 1675237625-229231 X-HE-Meta: U2FsdGVkX1+50XxtOA4PN3OyS6ew8Xti6i565gdVP9lYaPLaX1qXdYO/y7WM/Wg29kcCI1flj6vlpHX30O6X4wyY1HDy0muwyOVad4NXb//N7vAkhm9HVvwNcLuxNlQenIeSy+JVfdj1itXyP9170M21TOvhs7wFhBHVwbYzrzDX6ew1L+ZdThzpdWlFJEM45S4ZApz/eVXbsr7r650I8gvW468hwu7T2z21B2YPa1FPrex5UqD2tBzWqEXK7BhUPP4CbtG/ZuEBFDd+zRd3rj1+Ihklh/t/hQmYM+MrV2XotBu56NPW2G8UIkP7hSKGVEAa/3fhTsED0ut2zND24nreRH2XvsPFWfY49tfkFW0dwExioKvs9ThmyKJk6veUOBwRQZlXvS/rOcHwUJhlJEtdo/UEK3wtE/2eWE7dad4oXuHDyaCWbL1gJxbbW/+jGDiNaxIspzyCkumYRmRq1rBg/EPB1E3okPqv4MOad0ALueuc9OiBsecch4UmBQVzby0fo1jvkx4NMhrZhWzyb9ocAonZHIBtgXrifwIeDipuxO3lPGzeZ2bSmZ5IwYUaRdIiB8sZV5OpmUawAWUflGKSCkVcDtDbVH72MAcuo4ZuNPBXyBWsRSk8pnt9HwTtIZsoyUZU4VR3/LBjGr29RL5CMsjmhOGHdk9tm3GdCatthHVmpbZED7rzKem+arYCilYCIH3kG70AIfbjqdxkt6/befhMpXvSDEufDhu61HVSV8OwasPHoXP7uTuBln2unu3b6PwDGXmbHNMXwuFj+ZkaXgGuL2RUhccTzkaG29TOJnCUmD0G0EkG2cMit36oqIrokfTOAfIRQNYjwB66fREJaIs4NVgfhwMHgWexVbeHY5dDIwbf3HRX/4fKQw5JEdZTSqFq2wApV6M39PAvU8lYtjRudt2uMf4NI7/tDE1mZawK9aRihHdshwnLV3LavHFgPXPSsd+vrBJIVx+ GBamnOzK F7OkRBllZXIpCTF8wl5ExLeYQQG+tJafiso4yhTNF+fixGPtKHiDUByxra/iT4TbPcUK0xAydsQv3/G5GHIuX3Uu1SN06KUYEbWw23FulqWeIS0/Kw32nQl1sbuKa/pWLoHMTnyZCuDYqYohfwrrnZDkxgjdnBY5GEmV/a7RJ9iL524H1TTY1lL2YBjUH5IqwE9ccEUolhGaJ0r3juBU4uFtQzQmScGT2u+LQkknfz+43nIlRvQCfKmfyuq6pPsjP06+4vT6n1LuSstI= 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 Mon 30-01-23 14:08:47, Mike Kravetz wrote: > On 01/30/23 13:36, Michal Hocko wrote: > > On Fri 27-01-23 17:12:05, Mike Kravetz wrote: > > > On 01/27/23 15:04, Andrew Morton wrote: > > > > On Fri, 27 Jan 2023 17:23:39 +0100 David Hildenbrand wrote: > > > > > On 26.01.23 23:27, Mike Kravetz wrote: > > > > Yes, this looks simple enough. My only concern would be that this > > special casing might be required on other places which is hard to > > evaluate. I thought PSS reported by smaps would be broken as well but it > > seems pss is not really accounted for hugetlb mappings at all. > > > > Have you tried to look into {in,de}creasing the map count of the page when > > the the pte is {un}shared for it? > > A quick thought is that it would not be too difficult. It would need > to include the following: > - At PMD share time in huge_pmd_share(), > Go through all entries in the PMD, and increment map and ref count for > all referenced pages. huge_pmd_share is just adding another sharing > process. > - At PMD unshare time in huge_pmd_unshare(), > Go through all entries in the PMD, and decrement map and ref count for > all referenced pages. huge_pmd_unshare is just removing one sharing > process. > - At page fault time, check if we are adding a new entry to a shared PMD. > If yes, add 'num_of_sharing__processes - 1' to the ref and map count. > > In each of the above operations, we are holding the PTL lock (which is > really the split/PMD lock) so synchronization should not be an issue. > > Although I mention processes sharing the PMD above, it is really mappings/vmas > sharing the PMD. You could have two mappings of the same object in the same > process sharing PMDs. > > I'll code this up and see how it looks. Thanks! > However, unless you have an objection I would prefer the simple patches > move forward, especially for stable backports. Yes, the current patch is much simpler and more suitable for stable backports. If the explicit map count modifications are not all that terrible then this would sound like a more appropriate long term plan though. Thanks! -- Michal Hocko SUSE Labs