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 D43F2C678D5 for ; Tue, 7 Mar 2023 14:20:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 089766B0071; Tue, 7 Mar 2023 09:20:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 039346B0073; Tue, 7 Mar 2023 09:20:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E43796B0074; Tue, 7 Mar 2023 09:20:31 -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 D515A6B0071 for ; Tue, 7 Mar 2023 09:20:31 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 9A0D11A0CE7 for ; Tue, 7 Mar 2023 14:20:31 +0000 (UTC) X-FDA: 80542312662.15.DD54AF4 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf24.hostedemail.com (Postfix) with ESMTP id A2ED4180019 for ; Tue, 7 Mar 2023 14:20:29 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=LeYiLpFH; spf=pass (imf24.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678198829; 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=OGeuDm25l7pIlwQ6+UAa3/akLy9f+p8fTWJVRgtfmU4=; b=j9mIG97aMTiOmCxb4+q6iRzlozvkGrBbDfrEQz4pGScQ3s05HGRktXHysaTz/eWuyO+jt/ HX0YXPzcV9P6IwC9IyN1rZAeTkWrEAsOYEl6FlIHNKpqeoEU3lQ4cmRO3fLO2zLAdTJxp/ 80saCkmavZ8G1dJrIfypnPK7/grsahc= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=LeYiLpFH; spf=pass (imf24.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678198829; a=rsa-sha256; cv=none; b=Wneq8QEhjDErtmxbIJEiDWQyDq6IjxbtQjKb9EmAgaZHTsYKSNrlWjcJRoJbX8OoQfn1JA AC2k+kVEMtJJ4qhkgJ0gQS4snb9Zot1ZEVZQhXmjTVRV088vdLgY1ptenj4TWUSANQdc4y WkRpGd0gPLkD2btJhRgv4BneyedToCM= Received: by mail-pl1-f172.google.com with SMTP id a2so14226963plm.4 for ; Tue, 07 Mar 2023 06:20:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678198828; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=OGeuDm25l7pIlwQ6+UAa3/akLy9f+p8fTWJVRgtfmU4=; b=LeYiLpFHctF9fR7ykudTlA2w+uAmWZ47qqhuNI7NkTsshvbtwBNtTv/EVXBqJhHlw8 7OOZ43jpDZEuWiYlf4a7pGCxIqq8qne5tJtHbOVQa97pBBJn04XnQtPBI4Mv/gviw8De jD3l8FW53Nv9WdzW0aRrmc6crmVK5zpl/3X14lovRUwqnQWPXyfaHYWuLkpq6W/Hak5B GesjDcdTRh4ucGHMAG0yDdesvN9+VqOwUrDKqX3zvlfC83XYacr8Ocsl4EiJcqHbuM97 hPth980I/bY2xxwFMgUSFj8THsbjnI9A0a6GmG85OEWrg72OpJMgmO3SENBET+BxgJo5 HmQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678198828; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OGeuDm25l7pIlwQ6+UAa3/akLy9f+p8fTWJVRgtfmU4=; b=55rFOcsmWSSdeVDkw6HMtyd0O07wB9/A2ZRj1EM+yjFGymDkrR2F0VGnLXJVwrpppK RnveTEt+3/6Hkfdk8+dZpnrIL9xfGzSmgGgJ5J3grMxfMhBRo1vizuMrHesRiOGJYztj V0ydWM1Sm7SYvkAEQoB0m2M1VGMliWZDWU+GtM57coKfdjxJkxY6o6FjtZbEWM08EHlf BWPdRek3UBgsj8fjdZQci2COhN42YSSXDXYbq5G37ZDqW/F+GgkJ8hcjC0A77ZqSIQzU 9ulquw9ghN2pHcKwlcc5bOL22iUb8QxxEefhDFgIXKjqY+66B4waUJcpXYfBX7IOSvpS nnPA== X-Gm-Message-State: AO0yUKWRHteQqRp4vqwHFkfA2DS273J3ndu41pH3lo+5o0rMj4uE+5zM g5xuD6l3KgD+o+jPHt/5LI0= X-Google-Smtp-Source: AK7set//XoDivEj3N+uGgAm+/oYIUSG2OmdUvW4Yz8KCyqop3LqKCRH/KH1Q/j9YTS4WEsyrrBj5zQ== X-Received: by 2002:a17:902:b781:b0:19c:eb9a:770d with SMTP id e1-20020a170902b78100b0019ceb9a770dmr12538988pls.53.1678198828322; Tue, 07 Mar 2023 06:20:28 -0800 (PST) Received: from localhost ([2400:8902::f03c:93ff:fe27:642a]) by smtp.gmail.com with ESMTPSA id t18-20020a170902d21200b0019a723a831dsm8495517ply.158.2023.03.07.06.20.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Mar 2023 06:20:27 -0800 (PST) Date: Tue, 7 Mar 2023 14:20:20 +0000 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Chen Jun Cc: 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, vbabka@suse.cz, xuqiang36@huawei.com Subject: Re: [RFC] mm/slub: Reduce memory consumption in extreme scenarios Message-ID: References: <20230307082811.120774-1-chenjun102@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230307082811.120774-1-chenjun102@huawei.com> X-Stat-Signature: j3wh9be48r6iwwq9ow7dgm8dipb9fwxn X-Rspam-User: X-Rspamd-Queue-Id: A2ED4180019 X-Rspamd-Server: rspam06 X-HE-Tag: 1678198829-82016 X-HE-Meta: U2FsdGVkX18VTBAWRstpMfj0ErFkYUD3IYL36C1Bktvt8GT2MHo4YDApvGyoiAbyeLRWMNExRFCWksLG+4TmzHNQwmuCy0V34xvOdyx8FOmMAPELgmtLASKulyqbnVE47nZhnrJ4bB+VBJP+0iOZjFFkH6JP4PL10zLcvs+5vULZVJhC2xM9C6+bKhjZkoeeVNB9pHv7Ar+IeoWrnG1tqZK2x0rPc8llBIAxHP4iaMOgopb8YfNsIokX0dq7wHj9iu40wkGVMlnycGK+o4uBjbfLs5cFVZoZj0lxyM7dCXU5HBx/WLyiGI1l7VK4WqzPNoOOZ8AP+EKHy3TIsXgPOglZnm7oQvA82tsOchFOHcJXmB1LsimWiWYi6UvJch8dDLOweA2Zvwt+69IywoEVjnH5EVLKHfl++sjHlHkWiscH6tcP3eCryyGjL1tzNwDcAxDUBQXSPNWd9GHxXfrsqMPF1Mo+HUQZQDbRB8cQFkEbz5ofN5mWIZEd2mRr+jW0SIquR4bNr/dZyiiDhb0i154vPtsaq3ouCWVwVUMIzlhnnHshehVR60c1LaGXcNuH4mDXGx5kQCTcS2MhmqKcCnSfgdZ1yGmC2zkWVGb9g/KTlXyweakbwhiMoivWKJHJIc3muFxwGj4qB3YDyDx+N7hN5dPyrdP3P1Wv8f4s8Wi/W8lgUQLjIRQjySektV5Hup5ZvbSossd005y3DQpGUlYA3f9nVrE0/v67Z1Y90FIyjvEBz53DkuEnexVEyy5VusMZuMQL4RM1Koy9D1uNCgB3QVux86v9TAmrh5zd8kyW7DLobyxGyDHBAsMBsPSZpMYvZp9uCYAyTbJiJSsQLooJrnVirFRB+yveIizQdubOs1tRRyr0CVRojJKP4zds8l8x0htoDH5OzN0UIU0fh27KfEK+mnTnNEq2DP0pHE4bLBlLOrdz4e81ei/ZpHu/DzoSNQ97kJL2/Wnu+ee YSr9xCAn Hgo/YTLPY7Q7rcZsMLQvU5CGJWdWYlfKp6WGydq2gi/cKvyj6Fp3Cw12z+1cfa8P+WfNNDN1AmYYNUNaEmBnjTi78I/rUGpJGtzzIahRV/8o3WHgyoKxd9ZtQnfFjTXHN9Fo3VvkXC0nVzbQZ+5wjMEspjJ8YHiFwA/HFadcHMJnfUSOu6qPNvDvx19TvSn2exK72jw8ETNXoY7qcvULCH6gyOgWswFWWHTphrVzBexebLNwgVD3xpTUapljjjI8/pzlOhETeiWgGGGXh/ncw0Sybob9ELW9jQNXqbHrccSGBVV9/frzyhUlyxwfBy8ISpSH1/kgYiGhRTIgONATBmd7PBc9zrZrBuBzmXQFjzTWZ+D4Nr2nTm3u+dKYliwU0EWw4rgKK3Yg1bvspSnTn/F+yd4aod53qWhjjH9d9QhMBFVtyz0VhkETKuqNn4667Njv24YhvXfgMj+UeQeBY/uhpYWAx+j9Lb2+A04uepnd4D/c= 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 Tue, Mar 07, 2023 at 08:28:11AM +0000, Chen Jun wrote: > If call kmalloc_node with NO __GFP_THISNODE and node[A] with no memory. > Slub will alloc a slub page which is not belong to A, and put the page > to kmem_cache_node[page_to_nid(page)]. The page can not be reused > at next calling, because NULL will be get from get_partical(). > That make kmalloc_node consume more memory. Hello, elaborating a little bit: "When kmalloc_node() is called without __GFP_THISNODE and the target node lacks sufficient memory, SLUB allocates a folio from a different node other than the requested node, instead of taking a partial slab from it. However, since the allocated folio does not belong to the requested node, it is deactivated and added to the partial slab list of the node it belongs to. This behavior can result in excessive memory usage when the requested node has insufficient memory, as SLUB will repeatedly allocate folios from other nodes without reusing the previously allocated ones. To prevent memory wastage, take a partial slab from a different node when the requested node has no partial slab and __GFP_THISNODE is not explicitly specified." > On qemu with 4 numas and each numa has 1G memory, Write a test ko > to call kmalloc_node(196, 0xd20c0, 3) for 5 * 1024 * 1024 times. > > cat /proc/slabinfo shows: > kmalloc-256 4302317 15151808 256 32 2 : tunables.. > > the total objects is much more then active objects. > > After this patch, cat /prac/slubinfo shows: > kmalloc-256 5244950 5245088 256 32 2 : tunables.. > > Signed-off-by: Chen Jun > --- > mm/slub.c | 17 ++++++++++++++--- > 1 file changed, 14 insertions(+), 3 deletions(-) > > diff --git a/mm/slub.c b/mm/slub.c > index 39327e98fce3..c0090a5de54e 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -2384,7 +2384,7 @@ static void *get_partial(struct kmem_cache *s, int node, struct partial_context > searchnode = numa_mem_id(); > > object = get_partial_node(s, get_node(s, searchnode), pc); > - if (object || node != NUMA_NO_NODE) > + if (object || (node != NUMA_NO_NODE && (pc->flags & __GFP_THISNODE))) > return object; I think the problem here is to avoid taking a partial slab from different node than the requested node even if __GFP_THISNODE is not set. (and then allocating new slab instead) Thus this hunk makes sense to me, even if SLUB currently do not implement __GFP_THISNODE semantics. > return get_any_partial(s, pc); > @@ -3069,6 +3069,7 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, > struct slab *slab; > unsigned long flags; > struct partial_context pc; > + int try_thisndoe = 0; > > > stat(s, ALLOC_SLOWPATH); > > @@ -3181,8 +3182,12 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, > } > > new_objects: > - > pc.flags = gfpflags; > + > + /* Try to get page from specific node even if __GFP_THISNODE is not set */ > + if (node != NUMA_NO_NODE && !(gfpflags & __GFP_THISNODE) && try_thisnode) > + pc.flags |= __GFP_THISNODE; > + > pc.slab = &slab; > pc.orig_size = orig_size; > freelist = get_partial(s, node, &pc); > @@ -3190,10 +3195,16 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, > goto check_new_slab; > > slub_put_cpu_ptr(s->cpu_slab); > - slab = new_slab(s, gfpflags, node); > + slab = new_slab(s, pc.flags, node); > c = slub_get_cpu_ptr(s->cpu_slab); > > if (unlikely(!slab)) { > + /* Try to get page from any other node */ > + if (node != NUMA_NO_NODE && !(gfpflags & __GFP_THISNODE) && try_thisnode) { > + try_thisnode = 0; > + goto new_objects; > + } > + > slab_out_of_memory(s, gfpflags, node); > return NULL; But these hunks do not make sense to me. Why force __GFP_THISNODE even when the caller did not specify it? (Apart from the fact that try_thisnode is defined as try_thisndoe, and try_thisnode is never set to nonzero value.) IMHO the first hunk is enough to solve the problem. Thanks, Hyeonggon > } > -- > 2.17.1 > >