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 BAE35C71135 for ; Thu, 29 Aug 2024 09:42:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 39FBC6B00A8; Thu, 29 Aug 2024 05:42:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 351746B00A9; Thu, 29 Aug 2024 05:42:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17D246B00B0; Thu, 29 Aug 2024 05:42:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id EAF926B00A8 for ; Thu, 29 Aug 2024 05:42:15 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8F59BC01E7 for ; Thu, 29 Aug 2024 09:42:15 +0000 (UTC) X-FDA: 82504792230.11.4296B92 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf12.hostedemail.com (Postfix) with ESMTP id 2B87840011 for ; Thu, 29 Aug 2024 09:42:11 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="PkN/TZk6"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=BuuYwzT4; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="PkN/TZk6"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=BuuYwzT4; spf=pass (imf12.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 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=1724924414; 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=eisbvYeW6pkGrS9GN7zICg04QZo4gvnmxaiNhSyOy9s=; b=POWVIFpOlhN1hf2Oy6UYAmu4D+3xdGGnrNSsJsr9VxSqHM/4igo80750V9ctZ5oTNAB5i3 d1eQZdM9eBf/8uhrmATUBJMvFYFr3Ow0hbBjOMMscS0cXvnnTGPwVh5Vo7DYaH5sQMS3tU rb9GOJH0JfRDTLnA7/EzLnNC7KwDLaY= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="PkN/TZk6"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=BuuYwzT4; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="PkN/TZk6"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=BuuYwzT4; spf=pass (imf12.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724924414; a=rsa-sha256; cv=none; b=WHz6730O9eYLFHX2GlsPgTG6XSk2XrU6vVkUVtgeOUec8PxgRh/g4+XjjLcKv60IIx5tot W8/Oqh0qGHYNDhsdcV0b2ZeH5Gqr0syW8knOx00LjbD9mmWgdkKetPWY3wmvss+Fz1qkTS c5lbwF43Xo3smi50HuiJJa3gj7mViP0= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (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-out2.suse.de (Postfix) with ESMTPS id 74EAE1FD10; Thu, 29 Aug 2024 09:42:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1724924530; 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:autocrypt:autocrypt; bh=eisbvYeW6pkGrS9GN7zICg04QZo4gvnmxaiNhSyOy9s=; b=PkN/TZk649FNGZA9OoNowHx4iHVBRospOWu//FKW+anrVa3/rTEdvJRVCpKcvT/NRx+FJT qbFoSvoN37c0O3qDQ5oz0zpX60DeVz2PHuc7HRlO14eAzkTEzgwartOGmEiZBOa1cOl1LJ o9Qeho5UShUl7dPObNoWt1QuWyNmsxQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1724924530; 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:autocrypt:autocrypt; bh=eisbvYeW6pkGrS9GN7zICg04QZo4gvnmxaiNhSyOy9s=; b=BuuYwzT4MG2Y/GEUZqamtViymPseIxwNijuSC8/dR7eK1rYferY7pU/ucoGZSq8EgrJTPC xnhZZTjdg1qR/UCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1724924530; 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:autocrypt:autocrypt; bh=eisbvYeW6pkGrS9GN7zICg04QZo4gvnmxaiNhSyOy9s=; b=PkN/TZk649FNGZA9OoNowHx4iHVBRospOWu//FKW+anrVa3/rTEdvJRVCpKcvT/NRx+FJT qbFoSvoN37c0O3qDQ5oz0zpX60DeVz2PHuc7HRlO14eAzkTEzgwartOGmEiZBOa1cOl1LJ o9Qeho5UShUl7dPObNoWt1QuWyNmsxQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1724924530; 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:autocrypt:autocrypt; bh=eisbvYeW6pkGrS9GN7zICg04QZo4gvnmxaiNhSyOy9s=; b=BuuYwzT4MG2Y/GEUZqamtViymPseIxwNijuSC8/dR7eK1rYferY7pU/ucoGZSq8EgrJTPC xnhZZTjdg1qR/UCg== Received: from imap1.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 imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 5094D13408; Thu, 29 Aug 2024 09:42:10 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id vSFXE3JC0GZLdgAAD6G6ig (envelope-from ); Thu, 29 Aug 2024 09:42:10 +0000 Message-ID: <9fb06d9b-dec5-4300-acef-bbce51a9a0c1@suse.cz> Date: Thu, 29 Aug 2024 11:42:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] memcg: add charging of already allocated slab objects Content-Language: en-US To: Shakeel Butt , Andrew Morton Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , David Rientjes , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Eric Dumazet , "David S . Miller" , Jakub Kicinski , Paolo Abeni , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Meta kernel team , cgroups@vger.kernel.org, netdev@vger.kernel.org References: <20240827235228.1591842-1-shakeel.butt@linux.dev> From: Vlastimil Babka Autocrypt: addr=vbabka@suse.cz; keydata= xsFNBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+ 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABzSBWbGFzdGltaWwg QmFia2EgPHZiYWJrYUBzdXNlLmN6PsLBlAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe AQIXgBYhBKlA1DSZLC6OmRA9UCJPp+fMgqZkBQJkBREIBQkRadznAAoJECJPp+fMgqZkNxIQ ALZRqwdUGzqL2aeSavbum/VF/+td+nZfuH0xeWiO2w8mG0+nPd5j9ujYeHcUP1edE7uQrjOC Gs9sm8+W1xYnbClMJTsXiAV88D2btFUdU1mCXURAL9wWZ8Jsmz5ZH2V6AUszvNezsS/VIT87 AmTtj31TLDGwdxaZTSYLwAOOOtyqafOEq+gJB30RxTRE3h3G1zpO7OM9K6ysLdAlwAGYWgJJ V4JqGsQ/lyEtxxFpUCjb5Pztp7cQxhlkil0oBYHkudiG8j1U3DG8iC6rnB4yJaLphKx57NuQ PIY0Bccg+r9gIQ4XeSK2PQhdXdy3UWBr913ZQ9AI2usid3s5vabo4iBvpJNFLgUmxFnr73SJ KsRh/2OBsg1XXF/wRQGBO9vRuJUAbnaIVcmGOUogdBVS9Sun/Sy4GNA++KtFZK95U7J417/J Hub2xV6Ehc7UGW6fIvIQmzJ3zaTEfuriU1P8ayfddrAgZb25JnOW7L1zdYL8rXiezOyYZ8Fm ZyXjzWdO0RpxcUEp6GsJr11Bc4F3aae9OZtwtLL/jxc7y6pUugB00PodgnQ6CMcfR/HjXlae h2VS3zl9+tQWHu6s1R58t5BuMS2FNA58wU/IazImc/ZQA+slDBfhRDGYlExjg19UXWe/gMcl De3P1kxYPgZdGE2eZpRLIbt+rYnqQKy8UxlszsBNBFsZNTUBCACfQfpSsWJZyi+SHoRdVyX5 J6rI7okc4+b571a7RXD5UhS9dlVRVVAtrU9ANSLqPTQKGVxHrqD39XSw8hxK61pw8p90pg4G /N3iuWEvyt+t0SxDDkClnGsDyRhlUyEWYFEoBrrCizbmahOUwqkJbNMfzj5Y7n7OIJOxNRkB IBOjPdF26dMP69BwePQao1M8Acrrex9sAHYjQGyVmReRjVEtv9iG4DoTsnIR3amKVk6si4Ea X/mrapJqSCcBUVYUFH8M7bsm4CSxier5ofy8jTEa/CfvkqpKThTMCQPNZKY7hke5qEq1CBk2 wxhX48ZrJEFf1v3NuV3OimgsF2odzieNABEBAAHCwXwEGAEKACYCGwwWIQSpQNQ0mSwujpkQ PVAiT6fnzIKmZAUCZAUSmwUJDK5EZgAKCRAiT6fnzIKmZOJGEACOKABgo9wJXsbWhGWYO7mD 8R8mUyJHqbvaz+yTLnvRwfe/VwafFfDMx5GYVYzMY9TWpA8psFTKTUIIQmx2scYsRBUwm5VI EurRWKqENcDRjyo+ol59j0FViYysjQQeobXBDDE31t5SBg++veI6tXfpco/UiKEsDswL1WAr tEAZaruo7254TyH+gydURl2wJuzo/aZ7Y7PpqaODbYv727Dvm5eX64HCyyAH0s6sOCyGF5/p eIhrOn24oBf67KtdAN3H9JoFNUVTYJc1VJU3R1JtVdgwEdr+NEciEfYl0O19VpLE/PZxP4wX PWnhf5WjdoNI1Xec+RcJ5p/pSel0jnvBX8L2cmniYnmI883NhtGZsEWj++wyKiS4NranDFlA HdDM3b4lUth1pTtABKQ1YuTvehj7EfoWD3bv9kuGZGPrAeFNiHPdOT7DaXKeHpW9homgtBxj 8aX/UkSvEGJKUEbFL9cVa5tzyialGkSiZJNkWgeHe+jEcfRT6pJZOJidSCdzvJpbdJmm+eED w9XOLH1IIWh7RURU7G1iOfEfmImFeC3cbbS73LQEFGe1urxvIH5K/7vX+FkNcr9ujwWuPE9b 1C2o4i/yZPLXIVy387EjA6GZMqvQUFuSTs/GeBcv0NjIQi8867H3uLjz+mQy63fAitsDwLmR EP+ylKVEKb0Q2A== In-Reply-To: <20240827235228.1591842-1-shakeel.butt@linux.dev> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Action: no action X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 2B87840011 X-Stat-Signature: gb4x1eekjjxuw3md7nnffkseesfqfbne X-Rspam-User: X-HE-Tag: 1724924531-275811 X-HE-Meta: U2FsdGVkX193rlDFQlJLLrkhOcy+3GGSFO09NBXts8iQ6LX7MMtt/viUx01q0AHy4GyDfXJpM7rfVXgxe5bwsd911yA8CpSh9ogWNhe6DclfOIahHYO5CyYEjcc8lCEYTFh3ZHtWpFSVfCP+ROINfu/9cgrtsialovNdIbqDRVqd5G9d3EjX40eSs8DnKIoa5LGPCu+zv8ayubYaDJj9NnTaJfTGYly6FrBAOiCiGhWzh99DTmOnYyLQzd3+1hEu+T0T47qFCKHincZ3y+5gtZArdGleADpmMYWlm7/Kjsuwwa2+kaBsqfp1Eyzov9rxT+HLLMWi89qK9if59UF4Qf0GfUPtUj6PAkGHm/QAYBioUBrEYaqNc5C/JoVXWEUWCvp2MJ7Aw8/fz2+8w70gX1hNXHawpKQ3E1TE0E6vEyL8Z1QmFsfYdeErlnWTpTEvbWx3aOg56bSvetDMLDTzB3OjYjyutkgM8F3UVE8QujALOKMUbZ/thBBtfYr1YeR1KuEKsIycf4SLoBK/bHET9HgoE8P1/12RPm4+9YkP3tpucU7SLxCHpkEdLHaSQzApQdl/l+iwwxI34DGWOrkt/eL4bcGoT1BHgVoyCvwGjk7rJnkVSXmrcC6QGaD/Atf8gVurDF0x2mRHjLbACL3pyzaZp8OjYMn3TInzxspUZAJnHpeMXZwX9gHwXkqBGunIAUJ0M0cWxEyp/HWYy9sk0IBnqYFoBOqD1fctVXmRFFzCQo0CHtxNT5yp42+wdQgbqF6HvvracLNhvAnR7wO4GrNoSV7twKtgvCIoE4qYaoViHLWYHOORmSpazVH2mz3dCMrnlPHAetTgj+zLGo6qyYuOlaCWtciFT0V5thEfM1tbhvybCc807hJHMb+HWJqaXg9rGCDtPERvrpA1ux7gkrk3LKiw574/7Jtqv/6U7uMggxwNoY3zfTCNps6ytVu7DRRMLW5YPe5fVfn7Mas 2i5V20mT bufR87Yy7rcOqarsl9m870nBKkKHiNyXKNwV4OMq8/FeofCpRWYeFq12JV057gHONabqI+r6Km5cpi71gPKr/XqWNE8II4ZmybsbTqNUyDJSu2Y+yvAgjBSTN9ggw7qITFa/Cmphp1+gd3HB3Heeg7GyH0O6d05UEFHEJ5rBeUsWjVE1dzPcHpws+nTFWTMS0U7Fc+hPkv1GFU12NanQgfAXF8ZeOWLI0IPMY7RTSSahDeEV1u1WUVf7ED7Ys5zX1fbHSL6kxoJB+aD4CdDDvCUm1Uba2PUugJviFZIXfYn25Ww+ydERs2EvtZS3d8uwCOyFy7d45cOtlR1vYLcBr5ZakfEskIzdHIOzExobql8Ci7q+6sSw9GrW18Ulw+7x7kq+ySvnI1C/labvVFYZKPrPTIHuENmnQybWJmpB6/ixRw2o9mw86WM/DVzwAU1xutM2R 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 8/28/24 01:52, Shakeel Butt wrote: > At the moment, the slab objects are charged to the memcg at the > allocation time. However there are cases where slab objects are > allocated at the time where the right target memcg to charge it to is > not known. One such case is the network sockets for the incoming > connection which are allocated in the softirq context. > > Couple hundred thousand connections are very normal on large loaded > server and almost all of those sockets underlying those connections get > allocated in the softirq context and thus not charged to any memcg. > However later at the accept() time we know the right target memcg to > charge. Let's add new API to charge already allocated objects, so we can > have better accounting of the memory usage. > > To measure the performance impact of this change, tcp_crr is used from > the neper [1] performance suite. Basically it is a network ping pong > test with new connection for each ping pong. > > The server and the client are run inside 3 level of cgroup hierarchy > using the following commands: > > Server: > $ tcp_crr -6 > > Client: > $ tcp_crr -6 -c -H ${server_ip} > > If the client and server run on different machines with 50 GBPS NIC, > there is no visible impact of the change. > > For the same machine experiment with v6.11-rc5 as base. > > base (throughput) with-patch > tcp_crr 14545 (+- 80) 14463 (+- 56) > > It seems like the performance impact is within the noise. > > Link: https://github.com/google/neper [1] > Signed-off-by: Shakeel Butt > --- > v1: https://lore.kernel.org/all/20240826232908.4076417-1-shakeel.butt@linux.dev/ > Changes since v1: > - Correctly handle large allocations which bypass slab > - Rearrange code to avoid compilation errors for !CONFIG_MEMCG builds > > RFC: https://lore.kernel.org/all/20240824010139.1293051-1-shakeel.butt@linux.dev/ > Changes since the RFC: > - Added check for already charged slab objects. > - Added performance results from neper's tcp_crr > > include/linux/slab.h | 1 + > mm/slub.c | 51 +++++++++++++++++++++++++++++++++ > net/ipv4/inet_connection_sock.c | 5 ++-- > 3 files changed, 55 insertions(+), 2 deletions(-) I can take the v3 in slab tree, if net people ack? BTW, will this be also useful for Linus's idea of charging struct files only after they exist? But IIRC there was supposed to be also a part where we have a way to quickly determine if we're not over limit (while allowing some overcharge to make it quicker). Because right now this just overcharges unconditionally, but that's understandable when the irq context creating the socket can't know the memcg upfront. In the open() situation this is different. > > diff --git a/include/linux/slab.h b/include/linux/slab.h > index eb2bf4629157..05cfab107c72 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -547,6 +547,7 @@ void *kmem_cache_alloc_lru_noprof(struct kmem_cache *s, struct list_lru *lru, > gfp_t gfpflags) __assume_slab_alignment __malloc; > #define kmem_cache_alloc_lru(...) alloc_hooks(kmem_cache_alloc_lru_noprof(__VA_ARGS__)) > > +bool kmem_cache_charge(void *objp, gfp_t gfpflags); > void kmem_cache_free(struct kmem_cache *s, void *objp); > > kmem_buckets *kmem_buckets_create(const char *name, slab_flags_t flags, > diff --git a/mm/slub.c b/mm/slub.c > index c9d8a2497fd6..8265ea5f25be 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -2185,6 +2185,43 @@ void memcg_slab_free_hook(struct kmem_cache *s, struct slab *slab, void **p, > > __memcg_slab_free_hook(s, slab, p, objects, obj_exts); > } > + > +#define KMALLOC_TYPE (SLAB_KMALLOC | SLAB_CACHE_DMA | \ > + SLAB_ACCOUNT | SLAB_RECLAIM_ACCOUNT) > + > +static __fastpath_inline > +bool memcg_slab_post_charge(void *p, gfp_t flags) > +{ > + struct slabobj_ext *slab_exts; > + struct kmem_cache *s; > + struct folio *folio; > + struct slab *slab; > + unsigned long off; > + > + folio = virt_to_folio(p); > + if (!folio_test_slab(folio)) { > + return __memcg_kmem_charge_page(folio_page(folio, 0), flags, > + folio_order(folio)) == 0; > + } > + > + slab = folio_slab(folio); > + s = slab->slab_cache; > + > + /* Ignore KMALLOC_NORMAL cache to avoid circular dependency. */ > + if ((s->flags & KMALLOC_TYPE) == SLAB_KMALLOC) > + return true; > + > + /* Ignore already charged objects. */ > + slab_exts = slab_obj_exts(slab); > + if (slab_exts) { > + off = obj_to_index(s, slab, p); > + if (unlikely(slab_exts[off].objcg)) > + return true; > + } > + > + return __memcg_slab_post_alloc_hook(s, NULL, flags, 1, &p); > +} > + > #else /* CONFIG_MEMCG */ > static inline bool memcg_slab_post_alloc_hook(struct kmem_cache *s, > struct list_lru *lru, > @@ -2198,6 +2235,11 @@ static inline void memcg_slab_free_hook(struct kmem_cache *s, struct slab *slab, > void **p, int objects) > { > } > + > +static inline bool memcg_slab_post_charge(void *p, gfp_t flags) > +{ > + return true; > +} > #endif /* CONFIG_MEMCG */ > > /* > @@ -4062,6 +4104,15 @@ void *kmem_cache_alloc_lru_noprof(struct kmem_cache *s, struct list_lru *lru, > } > EXPORT_SYMBOL(kmem_cache_alloc_lru_noprof); > > +bool kmem_cache_charge(void *objp, gfp_t gfpflags) > +{ > + if (!memcg_kmem_online()) > + return true; > + > + return memcg_slab_post_charge(objp, gfpflags); > +} > +EXPORT_SYMBOL(kmem_cache_charge); > + > /** > * kmem_cache_alloc_node - Allocate an object on the specified node > * @s: The cache to allocate from. > diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c > index 64d07b842e73..3c13ca8c11fb 100644 > --- a/net/ipv4/inet_connection_sock.c > +++ b/net/ipv4/inet_connection_sock.c > @@ -715,6 +715,7 @@ struct sock *inet_csk_accept(struct sock *sk, struct proto_accept_arg *arg) > release_sock(sk); > if (newsk && mem_cgroup_sockets_enabled) { > int amt = 0; > + gfp_t gfp = GFP_KERNEL | __GFP_NOFAIL; > > /* atomically get the memory usage, set and charge the > * newsk->sk_memcg. > @@ -731,8 +732,8 @@ struct sock *inet_csk_accept(struct sock *sk, struct proto_accept_arg *arg) > } > > if (amt) > - mem_cgroup_charge_skmem(newsk->sk_memcg, amt, > - GFP_KERNEL | __GFP_NOFAIL); > + mem_cgroup_charge_skmem(newsk->sk_memcg, amt, gfp); > + kmem_cache_charge(newsk, gfp); > > release_sock(newsk); > }