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 B1F75C4725D for ; Mon, 22 Jan 2024 03:29:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CDFF46B007B; Sun, 21 Jan 2024 22:29:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C90728D0001; Sun, 21 Jan 2024 22:29:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B57D16B007E; Sun, 21 Jan 2024 22:29:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A2E8C6B007B for ; Sun, 21 Jan 2024 22:29:57 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 58C381A06AD for ; Mon, 22 Jan 2024 03:29:57 +0000 (UTC) X-FDA: 81705518034.13.CF20909 Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) by imf04.hostedemail.com (Postfix) with ESMTP id A064140003 for ; Mon, 22 Jan 2024 03:29:54 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=hjI7ixA+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705894194; 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=xf+pSu4bPzzZI2W7JvwVERQp95BfV0IRqQvQUdRUYfc=; b=Ghz4J5s5iSrhZ976n3ARDD0NirF9GgIIdZRFhTjQpCiLg/1xrgqc4hwAL/89Cy0ylNpXvu fU41nma0Q/BIwY40dil9aHAA9hZp5BfrU0or1jXYOZqAbFTTMmOxlFnxQwMekGUGuxL80P u6vYVn0yXGcPFUrblD7pBLg5h9+o/p4= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=hjI7ixA+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705894194; a=rsa-sha256; cv=none; b=BUvCxGbxlkraoBAwRXVms28vMblWb2LHkryqvIIZMsBpdCzCGzBx1ZSUINpqF5Mva4Rp5H H4AF7UXGVVUS+Ff9w19OjL12D5CxU62Bg4EWOuxbQ+hZLmu/saYI63Jc7G+oRekCaiDaId lpj6uScA/pwtKn9IFRXOaLRiXScZnec= Received: by mail-yb1-f176.google.com with SMTP id 3f1490d57ef6-dbe344a6cf4so2203598276.0 for ; Sun, 21 Jan 2024 19:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705894194; x=1706498994; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xf+pSu4bPzzZI2W7JvwVERQp95BfV0IRqQvQUdRUYfc=; b=hjI7ixA+4QhF6JIYncNfR1i1gN9uKU10FAZ56fNs9Ibo23ng1ztzB4+u4JKpX8u+VK p4FZclMk1c6vLvbEZE+KhICelt83zLf5KpVWl1rb1/IoPkMJS7cxrDDRIJCYZWiyajc7 wxsewYWu5yXmOHs1BHHPU+TMtf9Nil0U4Y1hIwtiewv2XlaNYhppMELReM32iNLfS00/ b183oxGN03m4atRNFY3cVpXOlnuMQ4i5eM0YHeXZgjDE3Zpr3CJy+oqiizryHpIHyoa5 UpSQ0DTffdPS6TgQPKTgxBYfX53yq4kKFgOVgW25hsslFhErRg5GA6ZNCMaeXE5v4cFv xk2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705894194; x=1706498994; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xf+pSu4bPzzZI2W7JvwVERQp95BfV0IRqQvQUdRUYfc=; b=QJHDPJUEqCK4WETYq98mAwgAfdyH9LXUPnuVK88aBcxOm0gATrV0amiJwXzS+J7ogx PjSAZMSZ/zUpZkCj873rlzfAZ/+RqobkhynBkQMBCQ80pXGSO4kUWb3sY/jMnkOXErKo 8noOHgpP//O6UppDVmfXUCQkQNiUekztkYGTFzPEboArEeZNm+UlhUb9zsdvyEmzhIpc 34jiVN0dm5wD6LWKLshwe9YC82yCUuaI5PkeM0vp6z+nVDglc8Mn1c+B+q3wVspRvTnk V0vD/llCDpK9NNT+PBB7d5LpaQZUd6l8iHw4Joek74ZGWWttXLWnTdTHy8GIHpEJGJa0 37ag== X-Gm-Message-State: AOJu0YxscSlf9jpXo3BVPkXmT1Ah6NTrcR69/v/DyUJbWd8wtwbZGU3M PN1QqzYh22eIOzGeyRQIaL53vwNXIrdKIA/1/jrfNOL9k7PPrSNMtfhCRsNfJgy5hpE9Xp2gzPK rsL0simGV7Gj9cD9jjRZBZPCUE8Cei9D3LZ3f X-Google-Smtp-Source: AGHT+IECg2K98D/NXHJLefj5mL0s/mzJRp5qfcZTN4YBXtGn6v9QKjw3AYrT/VtSj5Q0OsC/Ofamgsr/WiUdaiQNAmA= X-Received: by 2002:a25:268b:0:b0:dc2:2f4d:5209 with SMTP id m133-20020a25268b000000b00dc22f4d5209mr1502852ybm.100.1705894193555; Sun, 21 Jan 2024 19:29:53 -0800 (PST) MIME-Version: 1.0 References: <115288f8-bd28-f01f-dd91-63015dcc635d@suse.cz> In-Reply-To: From: Suren Baghdasaryan Date: Sun, 21 Jan 2024 19:29:41 -0800 Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] Memory profiling using code tagging To: Matthew Wilcox Cc: Pasha Tatashin , g@casper.infradead.org, Kent Overstreet , Vlastimil Babka , lsf-pc@lists.linux-foundation.org, linux-fsdevel , linux-mm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A064140003 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: kr4k95ja836xnobiiq5j6usbxg3jddtx X-HE-Tag: 1705894194-676521 X-HE-Meta: U2FsdGVkX19uTHTh92N0OHeiSS4ep4qhXrN8MEGVyjPful2hnqVy7k7ju4+cfGvowB4YcC2ZEMnSrbv9fMCRpI7GLOwTIcuOxP3N+DyliY6ZBC30WH5JFV5devfeRHYdD8NgnQz4kGC/oDIpL2vGICJdqMFeHz+LKHOunGT9VP0pzmghJKxnL7hvUEQNVCpf14XR/Ed8BfHbs5DoG8tt9oy75M/OMhVMb6dfgaV2cXXJezW3Zc8pFguKTyxjlG41VIhNfquo/mNSXSXCu5K3Y71qRPxBaKoS+oGDX/AcSzFniY47o9TBd7XoZYUmytdjdUu1VKWq+OQBF0AQoOi+W9stZTsgYLLUOlEcyndZEhPt+RY2NlLNmDukC57ZAAiGFNGhyAaMqYtx54jhBCxT4oYGaGu1VdVyfMRZXLHiigZ6ELD+h9BSmBxau+3vmE9RHc6DNth8jy8W1yhBAoJkaZ/XADr3oUEqA5jegcl5CAriTSH7pD0w+R2XaOsvnpzaMDyd4wn42gbfWkycvOulZXnf2RKSaRQDPsC5qxm2dPPdrBNpcaccA5plGcXOKvOCWjNYIoUL12Jv7SP6ijDC2H5JE6zDEUJ3I2ckAfijzPV2CxZ5bYNAT7HdFpLyeKqyufRewAXmJlCuxvLd0JxU5tZ78aETqBnWQOMBdNI/nbQGX3JN1VzZJ46bZSl6q5h1WSsQCd+queA8ZdaVXtZWdcFSPm6DLyA9t9d2snh0rJ6e7KSXUcPSTYdK+U6H9nI5zZXoUW1AKWGgX6VhqrczJUyQKvCcGJaNdwiOEXfILlZbk8gd/fcJbeIxc1hmG7+Lqq4V/D8ar+Uc6nPrhpvqSYJbfGSsRI9RZwIzXZU/ohRzHqMNwmpvXoTGNmiTILgnFeF4xEqlK0nqu0Zovp/zhy2cpVt7vT0g1UtgQUWpb2MGMtBj2cE9CoizP3v10OrIu8oKh2rIgWscf9Ya+ae Mrzr5LLr +qPxcoSVOYzcmYg5sz7BsuyAun2Wv9rZzBy0ga2B509ySUsbYI1Ka6yJlNpcWoRD6a7vfes/7Fz7NfNPqQZylI5wLSLK6KB34Q2AeTeNZitegfDlqdGtp4tU4iiSqq7Co0KC49KdihxioPrKC3M2Kqa/oHglWr1ZXaJy/nv5RyfsqEVswxyWcYiGIYqXbON5TLFLG1vWPoWskG8fBntVEnyAPtSDaI5Tbu8IyaDVRihNjIAcVxbJKf8gXaWK9dh1co4rf+NbeqYULnnMJ4fG6M4f9ttVBeTHuSLXm X-Bogosity: Ham, tests=bogofilter, spamicity=0.000087, 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 5:18=E2=80=AFPM Matthew Wilcox wrote: > > On Sun, Jan 21, 2024 at 06:39:26PM -0500, Pasha Tatashin wrote: > > On Wed, May 10, 2023 at 12:28=E2=80=AFPM 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 n= ot > > > 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? My bad. I should submit a proposal for followup discussion for this year. Will do that this coming week. > > > 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.