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 508B8C47422 for ; Mon, 22 Jan 2024 02:21:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C11C6B006E; Sun, 21 Jan 2024 21:21:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 249F08D0001; Sun, 21 Jan 2024 21:21:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0EAD16B0072; Sun, 21 Jan 2024 21:21:29 -0500 (EST) 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 E668A6B006E for ; Sun, 21 Jan 2024 21:21:28 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 410CD1C1213 for ; Mon, 22 Jan 2024 02:21:24 +0000 (UTC) X-FDA: 81705345288.05.E6A0521 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf10.hostedemail.com (Postfix) with ESMTP id 74B77C0011 for ; Mon, 22 Jan 2024 02:21:15 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=r15nLcb4; dmarc=none; spf=none (imf10.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705890077; 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=w7rTMujnGS1vflDu+GGEO7dgVhJq77rHLVCuvhrlBNw=; b=edGAg5cxv70kTj0IHebMHKoq0VMENYnes67o/67673ktriMt4lVX/k+2YVG/4OrYr7DMI9 Cbir7Or0uD/6kw+7b+dIPuOdNIuQlRtBAbWJJDT7mPOoDE/oqtV9A/zD/PGxeE39I94K09 o0MN4jWOoPCzxvwVHkkgUqfTj2vRGXI= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=r15nLcb4; dmarc=none; spf=none (imf10.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705890077; a=rsa-sha256; cv=none; b=bF43/fQ++DtaACgzVp9XOKgDocerlOPQlu0WA4q5nxSF4bdPWyVbztSrK7Xr5qS5I0fUqK eh6Sb+STNTFV0xNvxwy373hWc9pOEc7kMy1pyI9/gE2Z9jnWakZGphL/UxpWeG2/Xys3eP M/revQ1AAMNjRU8cf4ziv7KHepMXD+8= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=w7rTMujnGS1vflDu+GGEO7dgVhJq77rHLVCuvhrlBNw=; b=r15nLcb4lZXOFEReq+PSbjJ7ng xbkLbrT8GEn3W9lv3x7ZawzVQNgte8xYDo3b9WDLsFiWoiZWwSajIf45L7coeZNZ2RH+se+i7ny/2 Ucxw2lqlQqeCC3XbibYH/IyfhJ+jTy4SDrUoh5CeEIStE6KRWBf7pTStSfrxIGrSNt4FT9cYFSXwF fa3dj5alJqdeq5orpv1178tOGbRRe6VAdGLgJFkvT57sM+qFCIvJZ9nK24zSpyZwCiWTpPcXWolkV dPwYxK2e2JXXY5gd6mSkI9HvQhOXo0vY8qLmLrD/JzaTiBgaMjHJzgn87Yq0ffdTJgxssIxR3mfyR hAMhHgcA==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rRixQ-0000000EYbY-2NBf; Mon, 22 Jan 2024 01:18:36 +0000 Date: Mon, 22 Jan 2024 01:18:36 +0000 From: Matthew Wilcox To: Pasha Tatashin , g@casper.infradead.org Cc: Kent Overstreet , Vlastimil Babka , Suren Baghdasaryan , lsf-pc@lists.linux-foundation.org, linux-fsdevel , linux-mm Subject: Re: [LSF/MM/BPF TOPIC] Memory profiling using code tagging Message-ID: References: <115288f8-bd28-f01f-dd91-63015dcc635d@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 74B77C0011 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: xhaz5gybphesp9fnau9t5g1gwt8xhqx8 X-HE-Tag: 1705890075-615079 X-HE-Meta: U2FsdGVkX1+SSVdgYgBdh6Fsrcr7Ih6kBi/j7uLRcRBcMNt9BOPonTdzY4yL8G3frGD9DWjwo2cqht5ZPDPZfrWgat+RCD92tSvMBIIAarfV5sbC9VfOIVk9Wfauan7MCvuRKXmYjTeQ3o/NNn24T4fkZcU21YXowdEgIK7ohrAiOEXG/enGzTdGl1NN9r8sspnkQVXLPx5ACtagYqfZ0m1tR7ATSEd8U38sFkBgYGpeCDGs8dkWG6IPSa/M3cVjHFAAyvZ7UMmQjO3NGcuJ0XvPY+83m4wXSNisyxWdyDm3fy2FF9LIzTvsq7l8ImW2ftaH00ZIdUdeg7QdpB0chcHIBCiEa9XwZ8iuowzFw4D8h2Inp0/54y9sUdN1KAQDSOx1U1sIDkzHsdb541kx/I4u8Gh5FUzRzG9EbOWdpbK3sx29jODH1hyfEMJqmBcic51N9vDyISQJQLU4PDOjV1ysKVLENkM9Rcy4edTuwi4fmbotRvMW4LmB72D8ge2SL0l5AhBXvFal/vjBO7tXSf/j4pjeGI+J3RUnlEyVkPzHCdtx7lKtidooqv8+c2zktL9lq7WODpEVKFaakQkd26J0ls9oQSdSOMZz6w2YMR2CA4b3YcllYUwT7M3PJuua+gxHAFUexi90U6pMcsLtLe3PNDkDtL7UNVu1MgZCYfzv0ppWRs0D6m+XkoF3/bvlFhYJtz1MlLhjQv++6qqFix/IfBckOIJaLriIv9vIEGyiT6krc9w47oESsNQuDS2296Y1f3a0AXfca4RpcCKG9Rlt2f7AgDG5ar0bD4xSKjRBfQfKqQJqS1H7I3vFAxtjs8RtUSSdxSjf/XzNvGDB/ZRZLF85Ms63+jyHP4bDc+X7GXMXAiraLAF0lhzOhGh8nBvufrMcsEfAkyzuE8FAO4rfSNkH2giOCX9dFKJx80HK/nxa6z45fTA100sd319trn7rVcTsjIlwSnqBQIN DDbDU65x S+TJtBq2v2RYNrOruyekdC48XpqZT7zblYYWQ6oCM7QUsyyYsekwsUKpIxdUJv1yfjaxtAcTuIhC4NouV6pzGYE9KV6QR68XAZMVAq06WNOu6EFZ6x7D4WS0JzpaiKSXKXb+huzlU9uwpJ+ujHpXUcXhOeI1+4CDDXadHS+vFGY9cTlXL8OcmzBwnwRrCz9QsWxF/jzXTuw6N2anFE4WsofphPejPE8L4RYe7 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 Sun, Jan 21, 2024 at 06:39:26PM -0500, Pasha Tatashin wrote: > On Wed, May 10, 2023 at 12:28 PM Kent Overstreet > wrote: > > Hasn't been addressed yet, but we were just talking about moving the > > codetag pointer from page_ext to page last night for memory overhead > > reasons. > > > > The disadvantage then is that the memory overhead doesn't go down if you > > disable memory allocation profiling at boot time... > > > > But perhaps the performance overhead is low enough now that this is not > > something we expect to be doing as much? > > > > Choices, choices... > > I would like to participate in this discussion, specifically to Umm, this is a discussion proposal for last year, not this. I don't remember if a followup discussion has been proposed for this year? > 2. Reducing the memory overhead by not using page_ext pointer, but > instead use n-bits in the page->flags. > > The number of buckets is actually not that large, there is no need to > keep 8-byte pointer in page_ext, it could be an idx in an array of a > specific size. There could be buckets that contain several stacks. There are a lot of people using "n bits in page->flags" and I don't have a good feeling for how many we really have left. MGLRU uses a variable number of bits. There's PG_arch_2 and PG_arch_3. There's PG_uncached. There's PG_young and PG_idle. And of course we have NUMA node (10 bits?), section (?), zone (3 bits?) I count 28 bits allocated with all the CONFIG enabled, then 13 for node+zone, so it certainly seems like there's a lot free on 64-bit, but it'd be nice to have it written out properly. Related, what do we think is going to happen with page_ext in a memdesc world (also what's going to happen with the kmsan goop in struct page?) I see page_idle_ops, page_owner_ops and page_table_check_ops. page_idle_ops only uses the 8 byte flags. page_owner_ops uses an extra 64 bytes (!). page_table_check uses an extra 8 bytes. page_idle looks to be for folios only. page_table_check seems like it should be folded into pgdesc. page_owner maybe gets added to every allocation rather than every page (but that's going to be interesting for memdescs which don't normally need an allocation). That seems to imply that we can get rid of page_ext entirely, which will be nice. I don't understand kmsan well enough to understand what to do about it. If it's per-allocation, we can handle it like page_owner. If it really is per-page, we can make it an ifdef in struct page itself. I think it's OK to grow struct page for such a rarely used debugging option.