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 73179E7717D for ; Wed, 11 Dec 2024 19:32:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D879C6B0082; Wed, 11 Dec 2024 14:32:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D0FDD6B0083; Wed, 11 Dec 2024 14:32:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFEB36B0085; Wed, 11 Dec 2024 14:32:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A24D66B0082 for ; Wed, 11 Dec 2024 14:32:23 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 571C9160D43 for ; Wed, 11 Dec 2024 19:32:23 +0000 (UTC) X-FDA: 82883672886.17.6C9F6D1 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) by imf13.hostedemail.com (Postfix) with ESMTP id 23EA92000C for ; Wed, 11 Dec 2024 19:31:57 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=FgZs5Odf; spf=pass (imf13.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.174 as permitted sender) smtp.mailfrom=shakeel.butt@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=1733945517; 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=d6OKcSu+YVbuCISkjoli9i0TNQdc3Qjeu3F6E9XWl5w=; b=RdlLtJse66Utp0Ie+9QMA4x1TVhjyfs1hEtb7DkQNS/4F7DpBmXyHD9uA9LYVGmgQry9Uw nqDp4ghe+jCigz+Q5wBwENcv8JpYfwglEdYSWRAlETsZGuTKtsBEE4HxeGbmDX2JmkDgiP 8DODz7L0iTyx+o+OMdz5D/VNs64KE40= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733945517; a=rsa-sha256; cv=none; b=F2rC6x5qgU3g/tqBuSAJvWuZX1ojlSspGAm18SnItumRHPWKUEonCy4xtMtkp15L9Q8EzN Y5LCtL5B5XOne9wEt0cztIaBUqeGcrWj7ADWRkiC0YL/LZUtZWq4E9oOsKB3gsbn4IWDoo fnxLwzUMRMrtp6FBcOc0lIkVGAgnmDU= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=FgZs5Odf; spf=pass (imf13.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.174 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Wed, 11 Dec 2024 11:32:13 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1733945539; 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: in-reply-to:in-reply-to:references:references; bh=d6OKcSu+YVbuCISkjoli9i0TNQdc3Qjeu3F6E9XWl5w=; b=FgZs5OdfWb6afsj7/smsy7sJVQABpKNv7zAwZeHzPS3rUpNZFOyrrr5I6xB60xY1IWmtcE MQIqtXpxW0q2ZPiQFH4dzjArfWHI0N1VfA7Jckurbg3LsoXDoFU75LE1MICsfWjKydVqP3 /HuIa0o/v1YFR+RZSQM4ODeoEn+jd/0= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Matthew Wilcox Cc: Johannes Weiner , Andrew Morton , Christoph Hellwig , linux-mm@kvack.org, Michal Hocko , Roman Gushchin , Muchun Song , cgroups@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 2/2] vmalloc: Account memcg per vmalloc Message-ID: References: <20241211043252.3295947-1-willy@infradead.org> <20241211043252.3295947-2-willy@infradead.org> <20241211160956.GB3136251@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 23EA92000C X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: 9rncboghsyurwhtuxu9mitnfa3a8fjcq X-HE-Tag: 1733945517-74905 X-HE-Meta: U2FsdGVkX19XMTd7fSmE34IvQNzXvx4ZLprCLxvGB+H2mB+CpQugAcAN5n9Cq9UZS83D4+pnoa03SJBQ18V4I1d2pjQ6Rjhl2CAhHzBQ8xn1cPh/K+xSct5JHUl/QyN+W61Yl0TKFYWoJIfihKP+qJGOk0763eiy8yjKi9O0v9BOjs/cDwJgSia+sycH51+nXxhHgxQ61lRf3Xb2KwOm3G78WnPwpLlMaWJv1T8wiR+eENvS2lEbrgSxQGLEOM9IzExU109N3vGzAuw+wZiSRv4o/WJ449XM7GP7eVjfsb0hbeEyxFzuzrlS/qCnCvb2Cx6OWDwJ4uqr4NkoWGY8EMgUVWJTDAfUN7wxmzL3lX4uvXzwGSbfYu2YjpRn42iLRG2a4TSApmf5WYdRjl1SB2CyZdKm8LBcrkxXPYinkNOCHY4+47bzAukxvuqDH4fCGP1eG75QfL7nWtM4zAV1oy171BRxJfJAoElWh8mqC06mFbGzozwpv8vz6b2P9jBgcOexgy+k4WLAbGUIsMBZiOcJVUKuc1rxeRXEjBi5dZ7vMScsv4LO5N5jA6EFvL1POdDapuSRhggDfZzZs4cnTi8sU4q3vTfQOgGqMhXgIIpcZ66Y59QkK82F9ZTEB6/RAdvnSg86LN/XfA3kPxorEeSA9OCBop42NLpsBFE1g3E9sNFciyu1ROCkNAB7dVlUSLf3FJwejPzfSznnGAfDl/I1lhbYsNeIn7Pu/CuSjXHCjldbO2emcILjwW+eKLB7qfUmj/0MSBlcVvWeP9hFleyf9Yjy4FnQZMRAIo1vSYaZJiRiE4F/q7dfECJSaedF+WjkJibS3FTzo4x2m1pj4Zy49CMReTZJ5Iz4eSkzdpAOWrCePfaNP/NKlpldulv7LSAXMI6XbnvPx1K1qNdIfOOCV8C16vq67Xw/ArX061HjaNLq61JFeowHV+lGfA0XogDpmMuCp7N6k8d2XTF sn4TD8S2 +ovaH7qvmfFXV+3PdfADS6m86hDElhv9E3t6QEvLbGq3IOlSJ1tgvWKrDai5a8BhQluAyEBjpKlljqtJv+ng5zjQhxtCuYsSt7ZFLcRbIuRu+CzE/QXOWL3UUq7vo9dEyuUJ2vKKehcOWiXAztKm2Q9Npdg== 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 Wed, Dec 11, 2024 at 04:50:39PM +0000, Matthew Wilcox wrote: > On Wed, Dec 11, 2024 at 11:09:56AM -0500, Johannes Weiner wrote: > > This would work, but it seems somewhat complicated. The atomics in > > memcg charging and the vmstat updates are batched, and the per-page > > overhead is for the most part cheap per-cpu ops. Not an issue per se. > > OK, fair enough, I hadn't realised it was a percpu-refcount. Still, > we might consume several batches (batch size of 64) when we could do it > all in one shot. > > Perhaps you'd be more persuaded by: > > (a) If we clear __GFP_ACCOUNT then alloc_pages_bulk() will work, and > that's a pretty significant performance win over calling alloc_pages() > in a loop. > > (b) Once we get to memdescs, calling alloc_pages() with __GFP_ACCOUNT > set is going to require allocating a memdesc to store the obj_cgroup > in, so in the future we'll save an allocation. > > Your proposed alternative will work and is way less churn. But it's > not preparing us for memdescs ;-) We can make alloc_pages_bulk() work with __GFP_ACCOUNT but your second argument is more compelling. I am trying to think of what will we miss if we remove this per-page memcg metadata. One thing I can think of is debugging a live system or kdump where I need to track where a given page came from. I think memory profiling will still be useful in combination with going through all vmalloc regions where this page is mapped (is there an easy way to tell if a page is from a vmalloc region?). So, for now I think we will have alternative way to extract the useful information. I think we can go with Johannes' solution for stable and discuss the future direction more separately.