From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 151C363B9 for ; Sat, 15 Nov 2025 01:48:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763171295; cv=none; b=rsHdN63B5va6+rDIJLddPfzHA6QboB+OB42TupmI9+CIBj1zCaBuE4f6d/mAA4kwnGAx/mF3n4dqPcLqbj7ZETolaL2an47OLx/vHGyYnDMqHlK49kr/xPv6yE9dEOFZLNZ3nijnrAp+6ECtGFjpXd2jpAs3gwFFUB36sGxHBhs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763171295; c=relaxed/simple; bh=D87jPQOiYZ6fr91ahpNe0YOpMiqCfNUGgZFzJGVVjDM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uP8gRBf9u3SJN3iPkSbTyLxmXhjnSv5iThM0spulSrg7h+/1uvqjs2Eth+dV1ra/T/XpQQQBRT87vUUCp6PRSkzBEqtCrTfFNVsPEbCH6SeRm6564cHRp80u8uI4tj1ZvrmJrEOpE4SGAvHZLfMlhqMdpko55FyA7xgAiQJS7kc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Caae3gRh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Caae3gRh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7E92DC4AF09; Sat, 15 Nov 2025 01:48:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763171293; bh=D87jPQOiYZ6fr91ahpNe0YOpMiqCfNUGgZFzJGVVjDM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Caae3gRhnVvHTL+Al6KhQ0YaUQxbtKv41e8aHV1lPY4zHcjF2zNR3r5B3fq65iM9L gbSnYtqlO9CUkUIi6eRwv94K4Gfu49JNPLCV6BNdWtvP8CQ8XB2mTU+7NkIpSdmagH DFNOW2TjiQATP8qb1Y03cf1p7KYHrKBqdTOHYhqHrhygVJPtwZ8tNF89asq22AN/HQ TGum8cCL3TijmdQEkn6HfnbQqZONd42Gth6Bsk9z66EGohqm8FPdvzty6YnE0q+NHt oHe9ubqftBbrMAUMExR1GCZlu1RnEkzrsJjtPS9bVxSUjg02FbtJtpl/pqIEU28U8t 1aV5QcLg5xxMQ== From: SeongJae Park To: Jean Delvare Cc: SeongJae Park , linux-mm@kvack.org, LKML , David Hildenbrand , Oscar Salvador Subject: Re: [RFC PATCH] mm/cma: Inline cma_sysfs counter hooks Date: Fri, 14 Nov 2025 17:48:09 -0800 Message-ID: <20251115014810.79376-1-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20251114110301.39316246@endymion> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Fri, 14 Nov 2025 11:03:01 +0100 Jean Delvare wrote: > Move cma_sysfs counter hooks from cma_sysfs.c to inline functions in > cma.h. These one-liner functions are only used once each, but the > compiler currently can't inline them because they are defined in one > object and used in another. Letting the compiler inline these > functions lowers the footprint and runtime cost of the sysfs interface > to CMA stats even more. > > Signed-off-by: Jean Delvare Acked-by: SeongJae Park > --- > Applies on top of my previous patch due to a context change, but > otherwise independent thereof. > > On second thought, we might as well move these functions to cma.c as > this is the only place where they are called, so it's hard to justify > why they should be in a header file. Opinions? I think that should also be nice. In the case, I think it can drop 'inline' keyword to let the compiler makes good decisions with its nice knowledge. Also the similar event accounting code such as count_vm_event() and trace_*() calls can be moved into the new function together. If do so, the function name may also better to be updated to represent it is not only for cma sysfs but general events accounting. Just my two cents. Thanks, SJ [...]