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 7C154E7718B for ; Fri, 27 Dec 2024 17:32:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ECE3C6B0096; Fri, 27 Dec 2024 12:32:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E7D106B0098; Fri, 27 Dec 2024 12:32:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D44E36B0099; Fri, 27 Dec 2024 12:32:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id B69AE6B0096 for ; Fri, 27 Dec 2024 12:32:24 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 5C447B0782 for ; Fri, 27 Dec 2024 17:32:24 +0000 (UTC) X-FDA: 82941431286.25.509E91C Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf03.hostedemail.com (Postfix) with ESMTP id DFCEE20003 for ; Fri, 27 Dec 2024 17:32:02 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=W7fU3FHB; spf=pass (imf03.hostedemail.com: domain of surenb@google.com designates 209.85.160.176 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=1735320713; 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=04SxCpsaZ7KCjEolpa+jFc5TEJpImpO+Qtvwvnqh0yA=; b=Z5cIZ11OVo44OXujbp2nsK656slTc7Jc3N7ECPP2H4eU3vn1WClFAuHFQ/YBjMDz/UyJtf mh8ElgBwlU18h8RE+bcQNEgiA4iFM4awm5pELdI5aKpvusXnuXp+Q4nB7caSV2nGPEZFrY y50VtTfyJMNVe+dQ1YqFThzvZd1YftA= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=W7fU3FHB; spf=pass (imf03.hostedemail.com: domain of surenb@google.com designates 209.85.160.176 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=1735320713; a=rsa-sha256; cv=none; b=C++e1lfhkgVbWmo0UlD0VkX8sPbeNrhm427cEPWoHGy/P/s9WAvw3zxp8ee6Coot2a183a YadgVa5DlEuJVim/8CtA2wgYopiXNOm0uSV/AZtW4+Lz/dS/eH/B/GyKCabKtMY45K7TlZ 8x+DwLD2be8xaPmf2DZFe5uLsNnHrw0= Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-467abce2ef9so1981841cf.0 for ; Fri, 27 Dec 2024 09:32:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1735320741; x=1735925541; 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=04SxCpsaZ7KCjEolpa+jFc5TEJpImpO+Qtvwvnqh0yA=; b=W7fU3FHBmGWKQVnmHhgPeVs2RPPxiT8Mv5DQ5gu8K9xKUJBLN/wLPpmp/J0cmKdzwv IxZqxU7S2XXoDHaY1HcJp3VpST4W1+/OhdfOsfzVwBFUVKJ0m7TtxNe2QE0fYp77tuBi ow5OVFCoGmaCjkyGb1KAYhK2OpF/zxmfzTtaNwOmomq5RMo3ArKeiI1lZMEFsqlSE+p7 KIxgelz40dOWcNfl8CRaGZYu0ekbQ1VPNlcvVLPwYi0PTQCGK+fgws2C9a7A5IOAq4s4 BDmzG+aFJl7KQqvJkMsx5YaQ79JLYhjsLeBNbEJvWRK2pa6uUv4F5ciZfX/4TSysuLCC YtHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735320741; x=1735925541; 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=04SxCpsaZ7KCjEolpa+jFc5TEJpImpO+Qtvwvnqh0yA=; b=Hg4jdO34DQtbpb+SysCaKPXopgeP3FS2wm46vstIzG3MiUg3O/sMoE88UuntIaiMND tUrB489Lpu3ppDfUHxoQwlUEYUXHiMiW/n87bPjWgkwgOtsPrACZF/Ih4jbwvPin0oly tKRgU0TiUxsngj0JNgFqVusUDGQeGUbTfTtIE1pJ+bMeCzSRRQcGqkxczKHihKNLSXND skq46U1Jm+hvHHJF4XtGI8tUKfX18duZfSHc2Vg3WmK5nIMjtMnLiwcxR6xXjyyw1kNo 6T78VRdIQ0VwSO/BSCxLNFtTaQL7rj8DTf4DpQVqKK5x/UZzwB0cyP+zW2ZahyGG3QHp kkkg== X-Forwarded-Encrypted: i=1; AJvYcCWEVdEbX+2nqRV34iBDTQF9Jjt5PhVvKAJE2DiCkoJyFtTaDLzlrVc1XYOV5deinjoKFtAskYvIjg==@kvack.org X-Gm-Message-State: AOJu0YyQwh6EqPz9wDdmxSsn/Vacdtug04AXh9ocFS8n+gPSakVw0r1d aBLHOHkgp6SEIuRQy8GmYsevlSc+oIYxHit8EQK//tUbpe92X1V8ICEXxWQ7kUztNlcy95MlGN2 g2JuOCaFpsSlk9ik6QOBE1SG5ArU5JifdCAG3 X-Gm-Gg: ASbGncue4FSE0Q4vKp678NAQZgnMiWK7EnDlZblacZLkOkHti7a9e/Jqp+jfB2ZLKTj 0m+qcfGAMfAjl913po58lGRvEwxT5JOKADioaNw== X-Google-Smtp-Source: AGHT+IFcBTHXKztvE10gZyJ3MYoBAJikURcg/HIDcbPftZvqfZcicz+LBrQC0kbUMElsmtxWbTj4Z7qSC3T+TnLLQuU= X-Received: by 2002:ac8:7f82:0:b0:466:8887:6751 with SMTP id d75a77b69052e-46a4c01bab2mr20251161cf.23.1735320741443; Fri, 27 Dec 2024 09:32:21 -0800 (PST) MIME-Version: 1.0 References: <20241226211639.1357704-1-surenb@google.com> <20241226211639.1357704-2-surenb@google.com> <20241226150127.73d1b2a08cf31dac1a900c1e@linux-foundation.org> <20241226162315.cbf088cb28fe897bfe1b075b@linux-foundation.org> <20241226235900.5a4e3ab79840e08482380976@linux-foundation.org> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 27 Dec 2024 09:32:10 -0800 Message-ID: Subject: Re: [PATCH 2/2] alloc_tag: skip pgalloc_tag_swap if profiling is disabled To: Andrew Morton Cc: kent.overstreet@linux.dev, yuzhao@google.com, 00107082@163.com, quic_zhenhuah@quicinc.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Stat-Signature: 57dp8zymomw9ph4pmoiaji9cds5p5ueq X-Rspamd-Queue-Id: DFCEE20003 X-Rspam-User: X-HE-Tag: 1735320722-247706 X-HE-Meta: U2FsdGVkX1/712SRTR9TDiC/jM/VTHAYT8KIwWEjRRCmm13Q90MM7iLB+1FFQ+iqywAYIVUyt9sCaD7cBuvlfZHCgo+Dg2pyOyQbC/Vz1U77MG5fj863oVDZr+all/3UJD4SYgb4zzz8CmhEpjW0ZlqnDLEpCCXi5LBz+dPJiH4DmQr2Mj/PyzrcJX5u4D6qvwtF+eJq6sljQAX9Ko9Wv1NsfKpC+1gFP8uVxafX79+6ogaEgh+YrPH9aDPu3/NO5s23R6N0VI48AJDsWGF/P4e+a5jZa3KTrr3AQVvod8nIU57FY5levl0aq5yfcqHCp5K9Zn/uRWk0p+lfL5dtwPXo5eQLwWnsomAIKlHfGLnQQQZg3zSecTut6xyfQ/5BwyL6JYUgAm4aO3nQ3ZTlj7xtf53kBfGHuCTqan8syHY2YUkEJ++jcYebCcCqE9vuK6swwRknNJYIeX6qYyLCYD4ykW/nxtVPWM4s7z54EFonhKuQd9oxoVtKjuMQ2vU8QmH8KZ4a+Zllhfe69jh6M7Ad0/d0ZRNQSCgCzg8Kyame6o9JecFIXsQJO3hE2qbAcj1q7/tk15nn/o3ReMB+BrCYT+DHL8wLjIPRwAJAseZXNJgFnhDpPaONSIYcq72YM8gbvLNtILdeNCPVVd/m/zV+2kaiIWjHdscSFv5zEKjTbf4Ev4VIVFpmqrdRKeL3k7jQclezk+z0FZd/ZNdRiQzS5nVdqoXmh2ZHQl4a2q+hxPDBHbyp3yjSRHi3NeVTncJ+j1JXRkZmB4NP5zmkdIMj7ay2/1WDU1Gd9lqZC4a3pSf+G7RIAnOiTHiTBXXeygQreJMv4MTaFpCP7r0dx3X8AL3npZf5f/b/4Mmd9gu9GvNRgAVqGbninGBzBviJ7Steq7SC2H9gyWnthLViJ2oLcp2IIyTeX4Lr+Jnq4EJ1FOkObOIh2YxISsM0L51Hmz1+i9xnuu+Baos8E47 7Sc/WSmm cdwoyIEcUrl6NqpmCNhMdddo5hLy4V/T+O1v2rnLGCUIFuYCAj7v2PHGEddxvbJLjylFdBDTvHp/nGb2NV80A9KReNIEQxHK7KjcuFLtc6VaGV41c9RI5wYwqU5rL2ew4MNzZCCUvb++BamFypW9bz0hWOU/33sgQSbvVSoEyzuuC289coO2kpWuPr1vNADiOel6DZxlg1eKapKvPFc8Vc7sJqAmXpEWDE1O0VfiIEitB4dDYLEqdkkbEdnyu9MVo5mtj9U7X126t3icRafRfucW1+vnPKW2bkisq6sphCYoYSUVl4Est+14y4b7Mhohy5IMqyRyXiwNYqqJKO/aco3BJ7g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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 Fri, Dec 27, 2024 at 9:28=E2=80=AFAM Suren Baghdasaryan wrote: > > On Thu, Dec 26, 2024 at 11:59=E2=80=AFPM Andrew Morton > wrote: > > > > On Thu, 26 Dec 2024 16:56:00 -0800 Suren Baghdasaryan wrote: > > > > > On Thu, Dec 26, 2024 at 4:23=E2=80=AFPM Andrew Morton wrote: > > > > > > > > On Thu, 26 Dec 2024 15:07:39 -0800 Suren Baghdasaryan wrote: > > > > > > > > > On Thu, Dec 26, 2024 at 3:01=E2=80=AFPM Andrew Morton wrote: > > > > > > > > > > > > On Thu, 26 Dec 2024 13:16:39 -0800 Suren Baghdasaryan wrote: > > > > > > > > > > > > > When memory allocation profiling is disabled, there is no nee= d to swap > > > > > > > allocation tags during migration. Skip it to avoid unnecessar= y overhead. > > > > > > > > > > > > > > Fixes: e0a955bf7f61 ("mm/codetag: add pgalloc_tag_copy()") > > > > > > > Signed-off-by: Suren Baghdasaryan > > > > > > > Cc: stable@vger.kernel.org > > > > > > > > > > > > Are these changes worth backporting? Some indication of how mu= ch > > > > > > difference the patches make would help people understand why we= 're > > > > > > proposing a backport. > > > > > > > > > > The first patch ("alloc_tag: avoid current->alloc_tag manipulatio= ns > > > > > when profiling is disabled") I think is worth backporting. It > > > > > eliminates about half of the regression for slab allocations when > > > > > profiling is disabled. > > > > > > > > um, what regression? The changelog makes no mention of this. Plea= se > > > > send along a suitable Reported-by: and Closes: and a summary of the > > > > benefits so that people can actually see what this patch does, and = why. > > > > > > Sorry, I should have used "overhead" instead of "regression". > > > When one sets CONFIG_MEM_ALLOC_PROFILING=3Dy, the code gets instrumen= ted > > > and even if profiling is turned off, it still has a small performance > > > cost minimized by the use of mem_alloc_profiling_key static key. I > > > found a couple of places which were not protected with > > > mem_alloc_profiling_key, which means that even when profiling is > > > turned off, the code is still executed. Once I added these checks, th= e > > > overhead of the mode when memory profiling is enabled but turned off > > > went down by about 50%. > > > > Well, a 50% reduction in a 0.0000000001% overhead ain't much. > > I wish the overhead was that low :) > > I ran more comprehensive testing on Pixel 6 on Big, Medium and Little cor= es: > > Overhead before fixes Overhead after fixes > slab alloc page alloc slab alloc page= alloc > Big 6.21% 5.32% 3.31% 4.9= 3% > Medium 4.51% 5.05% 3.79% 4.39% > Little 7.62% 1.82% 6.68% 1.0= 2% Note, this is an allocation microbenchmark doing allocations in a tight loop. Not a really realistic scenario and useful only to make performance comparisons. > > > > But I > > added the final sentence to the changelog. > > > > It still doesn't tell us the very simple thing which we're all eager to > > know: how much faster did the kernel get??