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 2BE82C4332F for ; Thu, 22 Dec 2022 16:21:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 59DE9900003; Thu, 22 Dec 2022 11:21:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 54E21900002; Thu, 22 Dec 2022 11:21:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41602900003; Thu, 22 Dec 2022 11:21:59 -0500 (EST) 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 320B8900002 for ; Thu, 22 Dec 2022 11:21:59 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E3F7E80E8A for ; Thu, 22 Dec 2022 16:21:58 +0000 (UTC) X-FDA: 80270458716.24.C7BD247 Received: from out-142.mta0.migadu.com (out-142.mta0.migadu.com [91.218.175.142]) by imf26.hostedemail.com (Postfix) with ESMTP id 3511C140015 for ; Thu, 22 Dec 2022 16:21:55 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="DCwHM/PP"; spf=pass (imf26.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.142 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1671726116; 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=QLJiu3habqMTelcjX0HdZ33w0IhCdBt7SxTNtmucJmQ=; b=mSknuPvlT62a8C0TtLMCPrsofDCENKi12Rm5NzpU0wIKBd687jPUqT9RbbS806ULHzcaN5 30vmDMha6Lu0Pae2LXSV9QhsQCMX220Dq/dN6k9CauYXow/KtJnwFAm0+0NWH0SiseQJVZ zbQg9FYpVBuDAVI1795sCg1i2TUFusw= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="DCwHM/PP"; spf=pass (imf26.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.142 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1671726116; a=rsa-sha256; cv=none; b=Z7AESNCZ0hwKELySI2s7lHhr5bV6W34zzzmOCvmk5jskTfmG+kJ4ZBweR6MYlInqMYh4+c u0+duV+xBm1rwYDenZBHtR6rnzd7i7Zkf639RjKGh6fxNKh9AshlSOemhroxHct5Zo7m6r KaDkoBRq4SocGSoyU6djhKsUcIsa/CA= Date: Thu, 22 Dec 2022 08:21:49 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1671726113; h=from:from: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; bh=QLJiu3habqMTelcjX0HdZ33w0IhCdBt7SxTNtmucJmQ=; b=DCwHM/PPgmNAHXq4GSR+kKVMPMlEFQKeQZ2UBipV7ptTv5n7G9a07wMDkYdSJfnw8UUcwQ lwe/N/lE9daABQOcAYbpYfhQaOoMrpX/vpDqQ4Xzkcyxt6mE88ioCpcBZpX5dmnwY1RIO4 V+lg6ecxOFTKibD2yj3ZCeENRIwuXLo= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Michal =?iso-8859-1?Q?Koutn=FD?= Cc: linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Shakeel Butt , Johannes Weiner , Michal Hocko , Muchun Song , Andrew Morton Subject: Re: [PATCH RFC 2/2] mm: kmem: add direct objcg pointer to task_struct Message-ID: References: <20221220182745.1903540-1-roman.gushchin@linux.dev> <20221220182745.1903540-3-roman.gushchin@linux.dev> <20221222135044.GB20830@blackbody.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20221222135044.GB20830@blackbody.suse.cz> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 3511C140015 X-Stat-Signature: 7k5f6ygxm68ct3z6djtd6sbttqqcr1tk X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1671726115-46432 X-HE-Meta: U2FsdGVkX18pjA4oSj3J+hlBup0ZwjjUlNGY4cZOA/r2rxQQ2+UDoC1unbRXnHfayila3AEr8CHp1Isd3Jz+IiDfQ51BUQDj6cuhWq7RS2rJIz1B978FbrhoMQxATdoAU86Ij1cs4Nh9/zNCOb66XcYX+g5bUST0PdU07jwGcbXeaSfejXExyp1iv/8Gz7skp+q+j7jsurNlJ4P8Kls75Is2VU1knuDV3RqTqsVkUi/GQPvWS2PwHo9FYeMjoPeO/9HoDdtOp5VS1mrkpNglT8eF3BENmb06/esTiJifVJaizbARMLntDD6FY+k2ueG7ClGTDNq8RFXY48iE1+Ow1Q68a8yl7gmDWzHTn9vfTnn3/TLyppe55TSsHgNwB/uGd74ByyvLAftv9i8VvTAJ5k8l8R2AaiPZyjS/N2eKvaSbjdbMYeHqJXdJEH7ZluCg+TXIXhTjn3Ltgq0x+evECO3Mgud1RaP5saKmJRPlqffVqw+j6ptj8/fQ8w29xct3ZRaPrEMfW1xvGq+wokTfPt4KgQTS1Jsy1EOu++pGlcSoylBhsXMfBxiuwlw0jjh5X1BecM1cgfGiYCeO3cD9WRW17ezphtl3V+RVRY4YcZ93kOmAbhHK66XUlVaTH26b7bCSwmY9sVH+AIWuFehuoAInmBhEc6yZVAwPYpFsSPVYkT2KPPU03qg/hPAjL3AC1iKNlaFKdXP0qm3TWQvqAPSLw6O4ZgJJomsBrjE2EFkAtNG/iMEM/nqK/dmmFBLU/t5sH5grknCwn4+3jRWfb7Vt30/wDVBoLU/M1l7gkktSHJ+u6D+jDX7dJlaOimjtWYAyLcT44i+/vTFPmRWaiOvezFhQvWBGS8a1mP/29zo= 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 Thu, Dec 22, 2022 at 02:50:44PM +0100, Michal Koutný wrote: > On Tue, Dec 20, 2022 at 10:27:45AM -0800, Roman Gushchin wrote: > > To charge a freshly allocated kernel object to a memory cgroup, the > > kernel needs to obtain an objcg pointer. Currently it does it > > indirectly by obtaining the memcg pointer first and then calling to > > __get_obj_cgroup_from_memcg(). > > Jinx [1]. > > You report additional 7% improvement with this patch (focused on > allocations only). I didn't see impressive numbers (different benchmark > in [1]), so it looked as a microoptimization without big benefit to me. Hi Michal! Thank you for taking a look. Do you have any numbers to share? In general, I agree that it's a micro-optimization, but: 1) some people periodically complain that accounted allocations are slow in comparison to non-accounted and slower than they were with page-based accounting, 2) I don't see any particular hot point or obviously non-optimal place on the allocation path. so if we want to make it faster, we have to micro-optimize it here and there, no other way. It's basically the question how many cache lines we touch. Btw, I'm working on a patch 3 for this series, which in early tests brings additional ~25% improvement in my benchmark, hopefully will post it soon as a part of v1. Thanks!