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 53CB9CFC505 for ; Tue, 15 Oct 2024 01:58:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D7A586B00AA; Mon, 14 Oct 2024 21:58:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D03FA8D0001; Mon, 14 Oct 2024 21:58:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B7CFA6B00AD; Mon, 14 Oct 2024 21:58:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 981F26B00AA for ; Mon, 14 Oct 2024 21:58:18 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E7F41A056B for ; Tue, 15 Oct 2024 01:58:02 +0000 (UTC) X-FDA: 82674176466.22.6A4EF86 Received: from mail-il1-f178.google.com (mail-il1-f178.google.com [209.85.166.178]) by imf02.hostedemail.com (Postfix) with ESMTP id 8AA4380006 for ; Tue, 15 Oct 2024 01:58:03 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=fUKF0CIE; spf=pass (imf02.hostedemail.com: domain of surenb@google.com designates 209.85.166.178 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728957449; 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=eWFuuUZrOpvWo7VozKGNJBHoN3oNzSCbMJ/S2gTUF+Q=; b=VgaIn9CWOq8R4EU+3gi0OdpELZpEfCUgsWtXV21JVlLMdZj4Fj1MgbIxulR1oAbFtYZhbM JeFdtXLY+9vEHn9A6x3kTnTu4zDBZmKHSEpYH1tP8bupXlCOjHHXedLZLlsLjisR1JIE54 Eg3TDNJUR0xwxAoEw//vwMP0ej1c6Ag= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=fUKF0CIE; spf=pass (imf02.hostedemail.com: domain of surenb@google.com designates 209.85.166.178 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728957449; a=rsa-sha256; cv=none; b=0+0GKSTWtdm/Kw/TxShRAMlUEIwmaOVIb7s/ocxWvIfvWHIcqdeu29+mHil0UCkK3CVI4f 2DnQBpCuAX5aH5Ot0oBA6p7JWCgZVMiVp0dOrvx3at84jGuPGFP+PISPChhNWuq/DF35W0 f9pe7mNd97hF1nPVY+EYQ5cmRw7n7ZE= Received: by mail-il1-f178.google.com with SMTP id e9e14a558f8ab-3a3b3f4b2afso974195ab.0 for ; Mon, 14 Oct 2024 18:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1728957495; x=1729562295; 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=eWFuuUZrOpvWo7VozKGNJBHoN3oNzSCbMJ/S2gTUF+Q=; b=fUKF0CIEgQJtqyd5XaltOTqX6iHESmhpaY6A8iDFfrmUKv/PQMvHSKNx6PLvZZfK0U TEqbPvt9oq8ELb5nnXBFWSrOnHW5tzxZrCO06UnZSqM1hNv5GoU439gJqPmn6Tqfuqwm PtkYScRpj0U4fInfnW2YE1kaDPlZxYt+TRsP9qGPBGrZ7XmQYhEDg+jqCo5ufTUKYUe7 wBN78K2dTuIkz7fjGc0iklbZHSOm05KNNE4ALFcLQx3pXAjqpBGfwMPJ7Qpv06q3i2j9 l1wEH3e03N2RVhaYsKR2/LJooxjPFAPZ8y5OPXiXkx+9zMLM0Lj39iTE35fZV6jw6DdU oe8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728957495; x=1729562295; 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=eWFuuUZrOpvWo7VozKGNJBHoN3oNzSCbMJ/S2gTUF+Q=; b=XRMidLGJBlnK0qwXEMhpH8uy3ICJtfQ8OrA+SCEQ80fqJ/eTzyZaSu82FjIqxFRSbp C6iW1hPJX9DTjA9ndidhp9PV6O3XZSn42HHP5fFjZah764z6OA2RRdzr1jbRDCeQFSuZ Dxgy6ztW5l8BCF++UiDo3Bl4ZInPIPzDxZPtvRozmjk00U1SPeIm6EPAzQ6SWbfiuxIq a+727ol/y9WG/0KMbQj8ut0+Pcnw7QdP6dgv4BDIqByYYFDxujon+fn3X17DaN8Dc9BH rbtLwCdD80OozLKtTJnSuCTm9QVEHjG2T7uRqpA9jRbusuiYbqzwVZvZWmnzS35U9anE RQ7A== X-Forwarded-Encrypted: i=1; AJvYcCXk0A3d/D2bgqo9E4Q5XxYC2SaqO1ChOVa3rYE9emg8JCAoejmEGIxb/mMiWVm+cwcztjFI+apUyQ==@kvack.org X-Gm-Message-State: AOJu0YzYzP64QHt5+iZVNaB7x0ilsJ4lBym2I93mexd/gJ1XbXiCirF4 rXR93nK46RmarYr01meUeQEsLsHktgdnpfJZsrdSzLeeML5h2MAwadaIkYfZgoF4rpqNVjxtPuI KwGN8PhaGwetlT1NZmGECSwvgJa6FM/fNBbhm X-Google-Smtp-Source: AGHT+IFUTrzSNCWzgxg6f1uRbvivc/cnaSRU5kEq8qHIf1qmpEoKpSwE8bxbRecx0+nraiD24B25H080NY7pzKulURA= X-Received: by 2002:a05:6e02:12c5:b0:39f:83dd:5672 with SMTP id e9e14a558f8ab-3a3bd2d7347mr12465425ab.16.1728957495210; Mon, 14 Oct 2024 18:58:15 -0700 (PDT) MIME-Version: 1.0 References: <20241014203646.1952505-1-surenb@google.com> <20241014203646.1952505-6-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Mon, 14 Oct 2024 18:58:04 -0700 Message-ID: Subject: Re: [PATCH v3 5/5] alloc_tag: config to store page allocation tag refs in page flags To: John Hubbard Cc: Yosry Ahmed , akpm@linux-foundation.org, kent.overstreet@linux.dev, corbet@lwn.net, arnd@arndb.de, mcgrof@kernel.org, rppt@kernel.org, paulmck@kernel.org, thuth@redhat.com, tglx@linutronix.de, bp@alien8.de, xiongwei.song@windriver.com, ardb@kernel.org, david@redhat.com, vbabka@suse.cz, mhocko@suse.com, hannes@cmpxchg.org, roman.gushchin@linux.dev, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, pasha.tatashin@soleen.com, souravpanda@google.com, keescook@chromium.org, dennis@kernel.org, yuzhao@google.com, vvvvvv@google.com, rostedt@goodmis.org, iamjoonsoo.kim@lge.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: 6q9c7q1aysi3gck9998is3q98feyixpx X-Rspamd-Queue-Id: 8AA4380006 X-Rspamd-Server: rspam11 X-HE-Tag: 1728957483-419078 X-HE-Meta: U2FsdGVkX18jAA6Y1r/dRaTuVUeEQZEBCcl78kZmAcpBNmPDNLvYlwQ2pkRY8hJGDm4tT3kXESkmIdPEhNjnJ2y/Z4188ewwe0q6yTbuOoTgyPLXCagiavH9YfJ32BSEBqyZfUWck0GQDRrIzh/Sku9L0+mdMWeGLq2dD1Hg+RUFgab19haPG3u5XzoNFumVb8EyOUxwH9IVzib/mVhUpZ2+Rs9jtEokI/Ij3oLzBk9bAimn7F5tZpY966MS8j6NCWgAIVJ61leysFEelMR156NDhJg5hOL7eZr85US52uoTDNTFNio9TbMlHd6EyOSjp7n6cUKlzUTrnzvCFj7Z8OpnwzHLHw7GLtTJ2RsAqibpuaOJn7pjNmHHvch2AP7kOz91o6beVD8Ltgz/bPGLti9RiozerTi6GoKtwlwa9Qa8JUwHUY80TLXl8E15NebIyJWHgULeP1l37eu/t9ns+3lHbEV6cKZjRaOztiz5yPdJYATNUyI5E3D2B03dDj8shB6bxyXL7MKvWu8ztt4vD5ffvHaN4F5+uFQBltM8XKNAv1gdSnZeqYlsaeDxUYE3w0HG7Pzck0WoGRijih+wSIV+GX+1T40zf6CQbikL5CbptJFj7KDdYwZl56LrpH4ColcitzzEQ0qAfhfQr4ru7qaS9u3Z4VP7pt6A1EXLRqnK3Er983aEZO7ajXS63l8TrQI/AbIKJBNPP2FkcAfACkicxt7yr6knHSyRROBCh+h2VMd0vs6FZnSceN5o9OPcS1++8qUTyISAu9aElXaOhp5vx4ajz6mB6vxBVaZzcvX8gMIGKOWZvDuhSDMzDsvb7d/Mpaz1vOc9EoCeR+cIuBA97ZGBlN+kwuiE8MnDkTxOcVpBsyRTahBue9zfjRQSlqB2Co/e6e1Zr26YKCm+ZIeJtebGEQpYBeBPGwSCcpKTqbVB0nWG/J6N93PJ3FohpyAFOvZE9EXp2pfUt6x 39fhkoyC nk6HEQPZZh+sLe3fIsrEIfm7IWuOpTr8PQVHOVqRexoHzjQhRsoNeRXMgFsZqYSBSZoUEFYzabNIQgPBgw8clbcTs6rd0rzM2wyvxhb/HV0VC5AeKA4Dji4sByR2+gXxZsLIQ2guZc955KjJ0TcyM7ELrTd2Ufo9qBvl/IZBLIYZ926IEF5AW+z/d9QLhlxdJLTBcpKgUCxNKZ37e1eDA7Wl+i0pOGVaKgjY3Oh7+kk1PhKxdM1PsedtKlUQ3Bb4Lc4VHBCEIwrUTFlhSPCGs+BYAwedQSV8HLC7Z8vgBkNFkajYuzevkXAQrZw== 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 Mon, Oct 14, 2024 at 5:03=E2=80=AFPM 'John Hubbard' via kernel-team wrote: > > On 10/14/24 4:56 PM, Yosry Ahmed wrote: > > On Mon, Oct 14, 2024 at 4:53=E2=80=AFPM John Hubbard wrote: > >> > >> On 10/14/24 4:48 PM, Yosry Ahmed wrote: > >>> On Mon, Oct 14, 2024 at 1:37=E2=80=AFPM Suren Baghdasaryan wrote: > >>>> > >>>> Add CONFIG_PGALLOC_TAG_USE_PAGEFLAGS to store allocation tag > >>>> references directly in the page flags. This eliminates memory > >>>> overhead caused by page_ext and results in better performance > >>>> for page allocations. > >>>> If the number of available page flag bits is insufficient to > >>>> address all kernel allocations, profiling falls back to using > >>>> page extensions with an appropriate warning to disable this > >>>> config. > >>>> If dynamically loaded modules add enough tags that they can't > >>>> be addressed anymore with available page flag bits, memory > >>>> profiling gets disabled and a warning is issued. > >>> > >>> Just curious, why do we need a config option? If there are enough bit= s > >>> in page flags, why not use them automatically or fallback to page_ext > >>> otherwise? > >> > >> Or better yet, *always* fall back to page_ext, thus leaving the > >> scarce and valuable page flags available for other features? > >> > >> Sorry Suren, to keep coming back to this suggestion, I know > >> I'm driving you crazy here! But I just keep thinking it through > >> and failing to see why this feature deserves to consume so > >> many page flags. > > > > I think we already always use page_ext today. My understanding is that > > the purpose of this series is to give the option to avoid using > > page_ext if there are enough unused page flags anyway, which reduces > > memory waste and improves performance. > > > > My question is just why not have that be the default behavior with a > > config option, use page flags if there are enough unused bits, > > otherwise use page_ext. > > I agree that if you're going to implement this feature at all, then > keying off of CONFIG_MEM_ALLOC_PROFILING seems sufficient, and no > need to add CONFIG_PGALLOC_TAG_USE_PAGEFLAGS on top of that. Yosry's original guess was correct. If not for loadable modules we could get away with having no CONFIG_PGALLOC_TAG_USE_PAGEFLAGS. We could try to fit codetag references into page flags and if they do not fit we could fall back to page_ext. That works fine when we have a predetermined number of tags. But loadable modules make this number variable at runtime and there is a possibility we run out of page flag bits at runtime. In that case, the current patchset disables memory profiling and issues a warning that the user should disable CONFIG_PGALLOC_TAG_USE_PAGEFLAGS to avoid this situation. I expect this to be a rare case but it can happen and we have to provide a way for a user to avoid running out of bits, which is where CONFIG_PGALLOC_TAG_USE_PAGEFLAGS would be used. Thanks, Suren. > > thanks, > -- > John Hubbard > > To unsubscribe from this group and stop receiving emails from it, send an= email to kernel-team+unsubscribe@android.com. >