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 D8849C7618A for ; Mon, 20 Mar 2023 09:12:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 077696B0074; Mon, 20 Mar 2023 05:12:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 027AB6B0075; Mon, 20 Mar 2023 05:12:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E315A6B0078; Mon, 20 Mar 2023 05:12:29 -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 D44A46B0074 for ; Mon, 20 Mar 2023 05:12:29 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 981DD40B57 for ; Mon, 20 Mar 2023 09:12:29 +0000 (UTC) X-FDA: 80588710818.18.086BC54 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf16.hostedemail.com (Postfix) with ESMTP id DBF1118000F for ; Mon, 20 Mar 2023 09:12:27 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="o9Qd7C/k"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679303548; 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=fvaDnbXQeHaNxiDysza4BLM3TL48monAcc4PQBDFBmU=; b=PfQdktlrXaukuH2VTTnHor5ncGTdJ6BZz2//9znVPbA/vVEtoeya1KfFEMuaPguiBN3TRD BwZk6VAHj8FOZQ0Wp4AwH7hzNPEgif4F7HDQxlfZwttJN9jv1yVyr8qRSRyVdpyR/pYwS4 ZpY4u2+KhUNdfKGu0wQ4TzBWFJSyTOg= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="o9Qd7C/k"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679303548; a=rsa-sha256; cv=none; b=Wjr7VlVGUwfZTJ5wR69gEv+Rl8LlP/5q96y2whfQVG76wki7f41zq+qpTd/DtEHJi16c0T Xc+XKGTPyysH7cFf3qQ33bIoSKaKtEjO9kX7dTMj19r9bUzWO14z9jVFWUz64MEVoTm1at XFNzf9y/3fpXSLpPGW2hAuIHmahtXZI= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B9B5C612CC; Mon, 20 Mar 2023 09:12:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3A3EEC433EF; Mon, 20 Mar 2023 09:12:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679303546; bh=6rNDRsJJPvw8KCM0VtEHgt3GOmCv1ZQUGOOi9vJhRjI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=o9Qd7C/kbDEyEwhfVSSXHQHEmjzdnlRMYzZRPNIXfpgU9zYPHVPZGKpji3O4lJePX WrN/IgSr5buQi+SL+Xw7M0q1ura4Q3VnChv+0nEBUQjTKCY7bIXn1icdLkbhjXDt6h Pkdcd0v2/ntNrwhcqkJYINsB+fLaJuU0c/4giF1DFx7bGwFtQBRXNG0Csmtt0fbxdE 6jNrnGxhu9Dpi3IW53HxZ5wTX/m0GyRdNpNQqGsQIAhtUSYHZ8APr+WuPvx/pi2ysa 65ARevYRc/dZ/eHCAD1JENvVw0TYldmlZJpZr8jq/VWnvcU6pab1G2GMSMgxc6QuOY 1kwhnTsiFlwqg== Date: Mon, 20 Mar 2023 11:12:06 +0200 From: Mike Rapoport To: Vlastimil Babka 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 Subject: Re: [PATCH] mm/slub: Reduce memory consumption in extreme scenarios Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <015855b3-ced3-8d84-e21d-cc6ce112b556@suse.cz> X-Rspamd-Queue-Id: DBF1118000F X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: c7djtp9d148j6gfyy3acrgorj76nqyzy X-HE-Tag: 1679303547-49692 X-HE-Meta: U2FsdGVkX1/MznToOj3//fG9ESzcDZeHN9WXvZUH7nqZKCYcxDIlX+5PDyeJD6Ux61BHBx4ZZK35zAtcso8SPPvDp/H4292MPr+vz0P25RgTjBIfZr1wYTgZD5SiGHcTZygbR6aFNj770caAjyQZe04to6TMTKczz7AILlz4b8x8GZqEsAk8677nVKmZvaPtIjA96Yhww9C+tIXXGJgA3cBKTHxvNNDywuFORF0SehUpQXfkWqNLbtEzmoKt0lakzpEn+ZjW10jxk12tlZs8a/YZQKmkZ4eQ0EJE25eF7KQ8hMquB7RiaqgI8wTGhsrhtg4IqxmP4hGGGbTdJEBnBhlt5G9gL4KXvkceH/+vglcGYr0dxnZNkBTdC15Wa/FLHXkr3kcMkawXerG3011yHrGKTbi1fXnNeNRlNbQjIlxaHVjY3DTB+fcRo4lb08iwoJ6GXNOjYU/vlQSl9hulc6fHTx75cFkx4W+yXbr8rjqb1ZulLb4YRC4o5iJgDILb1kXap/OkW/sfOvk1WxAb1VZDzKLnCDkjAE9VfWYyBAHSb7MPN+4czWkwzI+vjVTwao/RyKROHdM0FCv6rQmm+/eojj7+NrY8GorWJ3c0eStqgeftOAOiBiH7uB97M8CvivPaC1xbPZPdBvhBFUNCFI5Qnt9gJQy9Cut0YcvflcKyoGmft+jBO/LWXWEdWHaOa2++mJbyN4U+s296eycI1MzkuvrQG8LXoMo5f443FzjHJc4Tg0rfpI4orTLoESUi9Hy8iJuDz1SUZAlJhK5b80nMerCwrof2uFiLR9qKLHlv1fCiPDZxyw+XeNZABDZJL+UPdvwRWFxArI+Ab0quMUPa0Z8tnjACythRIBI8j+zZZUbGnc8xv9+gg8zUVTsPSq1vDaGdrKwkk1+aBFXvQ58iiEHlwhFR1ZmAlect8d7gIfJ1NFEDtHBEewvKqqDBtZ9fdFcp1hTa1CqQ2sr +3cTbNrH ou09UjXc/3nHThVNFCZJKxgPciP17RQ/+/gdUGIW3i6ltpMNix+nhxonyr/6DjAhUcIAPIWKrFsLJbL/pQomiP9SHBqzztH/OsovjLoRQIgh5x3anUcsA1LNYXtZxp2sQoE345I5xyejIN7dXiHbiNS53rjIc8e1FzSaFR+bEmZMk/36wCY2xkdLT2Z7r0OlHkUF/w3SbJc2R0ZQJ0vu13uQVCBBecHO+rAkWL8ve6n/LHNXtUno1PHqk/38aeS0NsGr+G7aXQdJKkifIY1ZVF4WegHly5+fnfvkdFeuYCkbDIHg+C2a9NEuNz26K8+vmmWRix6kCSdQp9g31rgvfq+2HXPAXMrlSLyxvBo9NsqSs9N6cOXak4rw1OgK1zniSpygfXdTKGYAvobdocRRhXqn7+fav+j2aZp+n/5wlZbimDbc= 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, 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 写道: > >> On 3/17/23 12:32, chenjun (AM) wrote: > >>> 在 2023/3/14 22:41, Vlastimil Babka 写道: > >>>>> pc.flags = gfpflags; > >>>>> + > >>>>> + /* > >>>>> + * when (node != NUMA_NO_NODE) && (gfpflags & __GFP_THISNODE) > >>>>> + * 1) try to get a partial slab from target node with __GFP_THISNODE. > >>>>> + * 2) if 1) failed, try to allocate a new slab from target node with > >>>>> + * __GFP_THISNODE. > >>>>> + * 3) if 2) failed, retry 1) and 2) without __GFP_THISNODE constraint. > >>>>> + */ > >>>>> + if (node != NUMA_NO_NODE && !(gfpflags & __GFP_THISNODE) && try_thisnode) > >>>>> + pc.flags |= __GFP_THISNODE; > >>>> > >>>> Hmm I'm thinking we should also perhaps remove direct reclaim possibilities > >>>> from the attempt 2). In your qemu test it should make no difference, as it > >>>> fills everything with kernel memory that is not reclaimable. But in practice > >>>> the target node might be filled with user memory, and I think it's better to > >>>> quickly allocate on a different node than spend time in direct reclaim. So > >>>> the following should work I think? > >>>> > >>>> pc.flags = GFP_NOWAIT | __GFP_NOWARN |__GFP_THISNODE > >>>> > >>> > >>> Hmm, Should it be that: > >>> > >>> pc.flags |= GFP_NOWAIT | __GFP_NOWARN |__GFP_THISNODE > >> > >> No, we need to ignore the other reclaim-related flags that the caller > >> passed, or it wouldn't work as intended. > >> The danger is that we ignore some flag that would be necessary to pass, but > >> I don't think there's any? > >> > >> > > > > 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? -- Sincerely yours, Mike.