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 932E8CD128A for ; Wed, 3 Apr 2024 15:48:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA5CB6B0089; Wed, 3 Apr 2024 11:48:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E55CE6B008A; Wed, 3 Apr 2024 11:48:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF5A56B008C; Wed, 3 Apr 2024 11:48:30 -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 B35466B0089 for ; Wed, 3 Apr 2024 11:48:30 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 35780160540 for ; Wed, 3 Apr 2024 15:48:30 +0000 (UTC) X-FDA: 81968652780.07.205398A Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf19.hostedemail.com (Postfix) with ESMTP id C13501A0017 for ; Wed, 3 Apr 2024 15:48:26 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=B9LTX7Lv; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=XpD4vI0O; spf=pass (imf19.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 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=1712159308; 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=7oNoIY5ww0gv3VU/TWODJLW0stHUYUIo7HrJ52y0BwM=; b=JqN0B3RgySzGm2+QoyaqaWMGbHs3NdZmKCYl57N+NNh4CeT8pYg+w/oJ1e8YeEjpKycX92 I2cc3t6JChCxoI2QocaBf4vdiSHRBth20cWiG9jbtomjOAI35XXC5/KoIsgaOY+SuJKh1S 9tSOSkELKSmjFxA7lehMu6duubE+TIA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712159308; a=rsa-sha256; cv=none; b=CCt5DtsZX8opNPGkv5iIiWDAcqe1sA1BTGy28nucjwowyl4ksLKiJBCJ2eBYPuEkJNQDeE fv7jv+AOd00Y9adSuXMv3deSTnzcx6HXTK5D/Q0mdyEaH479YIEILWf/TgNFOkfxNSVpyE 4R4EpUqRTw1ZOLRxnAh8MGXOaHaWDwc= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=B9LTX7Lv; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=XpD4vI0O; spf=pass (imf19.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [10.150.64.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id DE05234F5A; Wed, 3 Apr 2024 15:48:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1712159304; 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=7oNoIY5ww0gv3VU/TWODJLW0stHUYUIo7HrJ52y0BwM=; b=B9LTX7LvmmsyVU4sIRQovKvU02mdKjzNeFejSfw+KnhrXcUtGr/V1WGmTUvAgVVvwQKd3j +FV20M4Sv/CqK1RW2oe/0geQaAuA+pnzADleF4Hj3FTvlPB8ELNOiSLe8+PaWQwzUe+DBO MDzXUtk0PNOMmo1l1/IvzsLO1NG1bxY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1712159304; 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=7oNoIY5ww0gv3VU/TWODJLW0stHUYUIo7HrJ52y0BwM=; b=XpD4vI0OejctTDeIixHkLVdljXWdVHrKM7K1YjIYArDfpRXhwYY+7nUrsk3Om4eQ2vMdLU kTaPgCYV1K7kSbBw== Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id AA70F1331E; Wed, 3 Apr 2024 15:48:24 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap2.dmz-prg2.suse.org with ESMTPSA id aLZCKUh6DWbpegAAn2gu4w (envelope-from ); Wed, 03 Apr 2024 15:48:24 +0000 Message-ID: <4af50be2-4109-45e5-8a36-2136252a635e@suse.cz> Date: Wed, 3 Apr 2024 17:48:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] mm, slab: move memcg charging to post-alloc hook Content-Language: en-US To: Aishwarya TCV , Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-fsdevel@vger.kernel.org, Chengming Zhou , Linus Torvalds , Josh Poimboeuf , Jeff Layton , Chuck Lever , Kees Cook , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Johannes Weiner , Michal Hocko , Muchun Song , Alexander Viro , Christian Brauner , Jan Kara , Shakeel Butt , Mark Brown References: <20240325-slab-memcg-v2-0-900a458233a6@suse.cz> <20240325-slab-memcg-v2-1-900a458233a6@suse.cz> <30df7730-1b37-420d-b661-e5316679246f@arm.com> From: Vlastimil Babka In-Reply-To: <30df7730-1b37-420d-b661-e5316679246f@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: 3c3nuac6d1mt9ng9q4g85it47je19py1 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: C13501A0017 X-Rspam-User: X-HE-Tag: 1712159306-626379 X-HE-Meta: U2FsdGVkX18JQZ1yjqqzJ5VVS13aEOcSF4+6K1PU3vOEzsBQcKFUOmQRtvcvjKdG3X/a22ghWL53us6xO0FMDb0JlBYx/2+XPEacwbRa/QHp+vuCPYZrWwXhX0T0n82TYvyOQLer1p4HLItzqmdbvAVXF0dFtGlj3zp0sEFOztwQ0+C5mmQcE2hBg6WSLCT1/1Q7yDwpPsHGCF51GSLjTnJ2DwguX5U5l5uhurWwjqdVP852x1Op8904iude5Wb8MRvm196QVRX5WS0ZDn3+LDF0EEjjA6nowRIS0sAjoAo///aXTHgSWkwPyaN/XFunT7UgBZaY+7X2rKmKg+6FFwIKPUc7Z03uYAMmqVoua7xUEbbTVWYU9ar0KP1sqc+2ra+T9IZ0NIyRHoNrlnOLglcU0QIxsL8ZCz6/d8uLQGOPWEGb7M/UrP7Q78FnALsnh2e1jcy4R1TeDOyRzOHSfKfuPZOEnn3ch5XRuDMDOmJ2VmpH1GQfm5EdzxrE4IIrInfzDJnDOc1jE3aR4VrYj2i4nsoOCzoPjZpSOllud0xgOmDxFuN9QGgdiQYuGhxEVSTPXvBShwTVtntwxvBt7ujJiko8oA0phfbx03F1ih2PC/TMvRhORKnHdCCooVcdRISxyFH4ldDjfkTR+ogjCmdy7sZPQkpusAM56sBrAlrwT/L0K95lLHli+zOx+5+g5+8VL5BATNT5tMOEJQapxSmk592nh4D/J3uwABbqiIX5jzI8D55INGQgm3am2xNPFVgOthFFJg6Dbz6qhG6TxWjlEnwFG6nPtUmMt1shietpK7B+4rv5YZdX8ZH/zcXSv6/7Q9yJhx/4L2Gq3s+DYqeiCBymShett2UcmbFsGBX7KQjba+iUcmqLS7Hg/UCpBjLGgvYzq2WznNbGDr7lEU77KmlH+YNYQoc3aai+QmiuPPdF4MGr7fC1i1V80Z4OtiOA2DpvhzEXhO0JeEG ZS9JHVHL 59KDNaMZ8UqZjgMHL4AJ6giO7ZqGLtq6zXwlf 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 4/3/24 1:39 PM, Aishwarya TCV wrote: > > > On 25/03/2024 08:20, Vlastimil Babka wrote: >> The MEMCG_KMEM integration with slab currently relies on two hooks >> during allocation. memcg_slab_pre_alloc_hook() determines the objcg and >> charges it, and memcg_slab_post_alloc_hook() assigns the objcg pointer >> to the allocated object(s). >> >> As Linus pointed out, this is unnecessarily complex. Failing to charge >> due to memcg limits should be rare, so we can optimistically allocate >> the object(s) and do the charging together with assigning the objcg >> pointer in a single post_alloc hook. In the rare case the charging >> fails, we can free the object(s) back. >> >> This simplifies the code (no need to pass around the objcg pointer) and >> potentially allows to separate charging from allocation in cases where >> it's common that the allocation would be immediately freed, and the >> memcg handling overhead could be saved. >> >> Suggested-by: Linus Torvalds >> Link: https://lore.kernel.org/all/CAHk-=whYOOdM7jWy5jdrAm8LxcgCMFyk2bt8fYYvZzM4U-zAQA@mail.gmail.com/ >> Reviewed-by: Roman Gushchin >> Reviewed-by: Chengming Zhou >> Signed-off-by: Vlastimil Babka >> --- >> mm/slub.c | 180 +++++++++++++++++++++++++++----------------------------------- >> 1 file changed, 77 insertions(+), 103 deletions(-) > > Hi Vlastimil, > > When running the LTP test "memcg_limit_in_bytes" against next-master > (next-20240402) kernel with Arm64 on JUNO, oops is observed in our CI. I > can send the full logs if required. It is observed to work fine on > softiron-overdrive-3000. > > A bisect identified 11bb2d9d91627935c63ea3e6a031fd238c846e1 as the first > bad commit. Bisected it on the tag "next-20240402" at repo > "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git". > > This works fine on Linux version v6.9-rc2 Oops, sorry, can you verify that this fixes it? Thanks. ----8<---- >From b0597c220624fef4f10e26079a3ff1c86f02a12b Mon Sep 17 00:00:00 2001 From: Vlastimil Babka Date: Wed, 3 Apr 2024 17:45:15 +0200 Subject: [PATCH] fixup! mm, slab: move memcg charging to post-alloc hook The call to memcg_alloc_abort_single() is wrong, it expects a pointer to single object, not an array. Reported-by: Aishwarya TCV Signed-off-by: Vlastimil Babka --- mm/slub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/slub.c b/mm/slub.c index f5b151a58b7d..b32e79629ae7 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2100,7 +2100,7 @@ bool memcg_slab_post_alloc_hook(struct kmem_cache *s, struct list_lru *lru, return true; if (likely(size == 1)) { - memcg_alloc_abort_single(s, p); + memcg_alloc_abort_single(s, *p); *p = NULL; } else { kmem_cache_free_bulk(s, size, p); -- 2.44.0