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 40FB6C6FD1D for ; Tue, 21 Mar 2023 09:41:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8612A6B0075; Tue, 21 Mar 2023 05:41:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 810CB6B0078; Tue, 21 Mar 2023 05:41:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D7DF6B007B; Tue, 21 Mar 2023 05:41:16 -0400 (EDT) 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 5EB3A6B0075 for ; Tue, 21 Mar 2023 05:41:16 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 28F90121340 for ; Tue, 21 Mar 2023 09:41:16 +0000 (UTC) X-FDA: 80592412152.15.4507910 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf29.hostedemail.com (Postfix) with ESMTP id 14ABB12001C for ; Tue, 21 Mar 2023 09:41:13 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=hOtDvriS; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=P3EnkHVy; spf=pass (imf29.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679391674; 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=e86jmMfhyx3g3Qd21WKPXVLg7NEfwOFc8WYM94djY1s=; b=c1R2DQCzam00hztDWv8xjjDZcvQBOEjLTCSRoD+uPRLcu0K1bIUMuz3nTkIV10du2lO/z2 +LPIEGQc++VXuqRSKL2AZnWxkfaVDz874XwdAvOIZUJTNB2q1i5MBatnkc+XBPTbecMx+0 10VfWqk56zWaVzFXlIwcpQ5Ys40xdVE= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=hOtDvriS; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=P3EnkHVy; spf=pass (imf29.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679391674; a=rsa-sha256; cv=none; b=3lvygwfmsyseOYEAatBOXhudf7a4f8rszHzROhQiOB51DMhLZzlj5MFQViYEWVEWqq8VF2 POe9wBXTfcrtB9VCOTX74juCLpIXZGkYSrXg4/BfSuZ0L01M+8LBCxQBwOEH4egSd0O3aS eA7TtdS0iEn7C6Gx/d+FqVW4/CJ4jNA= 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 A371721A75; Tue, 21 Mar 2023 09:41:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1679391672; h=from:from:reply-to: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=e86jmMfhyx3g3Qd21WKPXVLg7NEfwOFc8WYM94djY1s=; b=hOtDvriSHngf2Um59z9J/Xm4r/QXMm1VvW0bn1bn4dLRaYvJtkkkjA4ERm/8hbvjXDyABf T+j6eOncRLjUdHpJGnzw7qlZ5m7nxPhkYS+kvHkaLwgpj/0p2MXErJ1DrIIQf1+E/+foo7 HweY4ijkswx9MQMMvHsqb39fvXLIwHQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1679391672; h=from:from:reply-to: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=e86jmMfhyx3g3Qd21WKPXVLg7NEfwOFc8WYM94djY1s=; b=P3EnkHVyN4KTsYuNwt92A+YLNu0wUuJOaOUbHxoz72R81jKN2YBJ4hvektWjxbq724Htl6 TsUSYCZczxwuIfAg== 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 6786213451; Tue, 21 Mar 2023 09:41:12 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id XGqCGLh7GWQxEwAAMHmgww (envelope-from ); Tue, 21 Mar 2023 09:41:12 +0000 Message-ID: <20b896db-9dd6-fcc3-a72a-ce0044d4ab75@suse.cz> Date: Tue, 21 Mar 2023 10:41:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH] mm/slub: Reduce memory consumption in extreme scenarios Content-Language: en-US To: Mike Rapoport Cc: "chenjun (AM)" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "cl@linux.com" , "penberg@kernel.org" , "rientjes@google.com" , "iamjoonsoo.kim@lge.com" , "akpm@linux-foundation.org" , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "xuqiang (M)" , "Wangkefeng (OS Kernel Lab)" , Michal Hocko , Mel Gorman , Matthew Wilcox References: <20230314123403.100158-1-chenjun102@huawei.com> <0cad1ff3-8339-a3eb-fc36-c8bda1392451@suse.cz> <344c7521d72e4107b451c19b329e9864@huawei.com> <8c700468-245d-72e9-99e7-b99d4547e6d8@suse.cz> <015855b3-ced3-8d84-e21d-cc6ce112b556@suse.cz> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 14ABB12001C X-Stat-Signature: r7wcbboqkatn9g5j3g3qmwets9ba5ado X-Rspam-User: X-HE-Tag: 1679391673-317595 X-HE-Meta: U2FsdGVkX1+sdVNrdTPlu95gmmN+Hgdk3uN4rq/9etl6aNDj9J2wAHMeU1sPaRjvYOg118p1+UtU8xWi4+9CE5rv28dRX+nXMHGYep7vGycr7gmjFUZanSKIhZmp8XwkE/H4gYgvw/NqNC4vJjZ0akfHajV3atvizEcp9w1j979IcUBhHPcbAvqpZDJ9b/nrSkFHKkiO8eslNS4tOFAvTVGe1GPdk00spWn7R8LEErOe1dctQRXmEwIxBAJc5tu4WVZLhMzIiFOlMaQDPPW44enGYDtOAs0pxr2OylOzVq1OiU4T4O8Zsqhp/4CBRkCP9r4v3g0L9+6FkQGwrJnGjdCD0h1/Bpy+JjWVeaMtEsxjACJwFtKwzFWe0u6nFzr9j5hsK6ekLdX3wX7Hsl7CvSRO713mJnwTr1oRD7c3aUkhHHGqBO53TIulMsfUaQCAw2znAFf48nGbg/HCGpu92A0OCgjrOzWAxk9L/Viv7ddjPYIcfqgJh4wAo3I2WjeP88f/KK2Vt1LF0/mn5fDqmeI/5tdVNPRzy3qZB5Nj9+esB/W/8d767xSo7XPlZ8Y72WLox7UdRjYA6gOSK8OpgPyr6l7lCCju6Di/ZVqJIGBRTiQpcaLllxDTmcgw0j+/1RxaA7uqyidMBZGFg/QlP7d6HH2mJ0V1+V2DAFZabyC2TiqrzdNgeKAyETEEtkv5MLAFVH2DjH5uHg3Zx0lZnQQ68B0hPmaezteqfdUmzVofMoNkdIgRFP4RstcfW+ttG25jSCXDAp3UsC6uEB8tpvLtdoBcYuygGGmRR3weBaxa2y7r3I6eA9eD7+H4q6D4zxRmyOYkeHD8iy3OhuKVjJpUIYnTjElFJBUmtLp/8B6fhUPeMAvTOt6uW85fMO1lV8Ul1tFP3cK5WCX8M59k7L5yY0D/xHk40LSTcnZwmuZO+Kx51uFAWtbDvoLifCxby8xJYO1Qwz0Ofj+IUFb TPu5a9LW dae4ofuKYS3H/4ABoycKvqJSYpsPkkpKK1rsKCqm/9c9qzUqBqf0Y10/H1R8Kib1tsgPBEeimpk48aSjQRLklIMw4kvwoP4YN6qf48RJxOI0ijpfZ/nrc+cA/zhYORiLQguUgyC/2pfU/fVVlxyhGKX/zUJa6HqMiasshYIXcP0vN8x8PrcNJBYAz5o/OoIzK7U30A8FvYk9azLFl1cpkigrFhU7WhjOxX+eLhWubkCkF6Yjuatck20CXCqPDkTXqKTBxIaqTYBY8eG3CAZOSf3fOoq67S79hlWnH2UEgoDnjT0Hd7k2gdwvpH6AuwuzCvqiwcCexs6qyXXQ= 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 3/20/23 10:12, Mike Rapoport wrote: > On Mon, Mar 20, 2023 at 09:05:57AM +0100, Vlastimil Babka wrote: >> On 3/19/23 08:22, chenjun (AM) wrote: >> > 在 2023/3/17 20:06, Vlastimil Babka 写道: >> > >> > If we ignore __GFP_ZERO passed by kzalloc， kzalloc will not work. >> > Could we just unmask __GFP_RECLAIMABLE | __GFP_RECLAIM? >> > >> > pc.flags &= ~(__GFP_RECLAIMABLE | __GFP_RECLAIM) >> > pc.flags |= __GFP_THISNODE >> >> __GFP_RECLAIMABLE would be wrong, but also ignored as new_slab() does: >> flags & (GFP_RECLAIM_MASK | GFP_CONSTRAINT_MASK) >> >> which would filter out __GFP_ZERO as well. That's not a problem as kzalloc() >> will zero out the individual allocated objects, so it doesn't matter if we >> don't zero out the whole slab page. >> >> But I wonder, if we're not past due time for a helper e.g. >> gfp_opportunistic(flags) that would turn any allocation flags to a >> GFP_NOWAIT while keeping the rest of relevant flags intact, and thus there >> would be one canonical way to do it - I'm sure there's a number of places >> with their own variants now? >> With such helper we'd just add __GFP_THISNODE to the result here as that's >> specific to this particular opportunistic allocation. > > I like the idea, but maybe gfp_no_reclaim() would be clearer? Well, that name would say how it's implemented, but not exactly as we also want to add __GFP_NOWARN. "gfp_opportunistic()" or a better name with similar meaning was meant to convey the intention of what this allocation is trying to do, and I think that's better from the API users POV?