Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp605554pxb; Wed, 27 Jan 2021 16:31:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJwRM6+tXXr8kTu5Y6UH1+t0q4gCyp/wMUNOn2hrAeIb7p45A8kXP27I+2x4QWJpkc4syUxd X-Received: by 2002:a17:906:c954:: with SMTP id fw20mr8640563ejb.342.1611793908230; Wed, 27 Jan 2021 16:31:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611793908; cv=none; d=google.com; s=arc-20160816; b=SVHvdIREfIBgA0B0U9sU1FVIloe1bWtom2qCL4Vt2BrYs3zYy9jKcLvR0Uv7AZuuMG G6iMXhLhXnR5zt4IfECFXxA2BsstFZCQj3eMbf5Gz5g125RBaUpbdKMkmRiFJh6Cyu1/ alXHz8HkTMPCtfRg9wZDuwxwjtOlTr8zgbSdNErUdi1kTgjbMGJDRaChm9KuvkcGMzLt bECMDEVUGlp2IZ3KxHAqXk0l8PCjck3VTYmgi6niTEJqYH1dGOl8ulD7xvRKFh50QnUf rDKRQbCW4I4FjoUgnmUTMbftj//wqxtDmHeGwFYHjYSRFVzyV/fxSdqmfNiF1TvhPMZ/ 6hvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=NHnDaep4soLIUVFgcK1vP1PkeHLaSM4DDjEPfhi0vRo=; b=Ff3bxJ20Za0hE7DsHBJ2G23jokpqitEVYVg9kepZFrM4SOMjRJKi620YgnCsoBHiDM 28QVphGGTsPvZWcSkCpJDHhDinTn3rFH28rodaieGT93peZmtY18UOHR5zVg+l2NDcQG 5JjpsN0cH7q8ZcPkNfxuPFcwInqgmCEg6fSZeYpptjx5TckJgrUy6p10P4Oer/SXCqYM AynS8H47udpK1qUsthIpTV+2EU9jkJiUTFKlUPCjSwhFYDyghMhLMEfiQCCERLC+mMjP PUyZ+mlvzzli56P/BcZIJe7IzGj9kPFFpzqw3feae/nt469AOyxYJ1rhgCnuuCxV+iZk Xx4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=U0jlcow9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u1si1469922ejy.721.2021.01.27.16.31.24; Wed, 27 Jan 2021 16:31:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=U0jlcow9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233758AbhA0VDv (ORCPT + 99 others); Wed, 27 Jan 2021 16:03:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44726 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233256AbhA0VDt (ORCPT ); Wed, 27 Jan 2021 16:03:49 -0500 Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E4C10C061573 for ; Wed, 27 Jan 2021 13:03:08 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id v126so3198538qkd.11 for ; Wed, 27 Jan 2021 13:03:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=NHnDaep4soLIUVFgcK1vP1PkeHLaSM4DDjEPfhi0vRo=; b=U0jlcow9OnWiQY4OJN0AVr7YhWpMtEtAkm3oUoC3kkSyPAl7bRLUPfNgYqhQICnuT4 abOxe8xPAYoqFVfUUFZ8oOmWS5B5QNbJN1DvQYmOanCy7Q6CB2KQZPk+HM8EDLCA/CEA 9QSbQCPLv7N17px5rsIYlPPHK64ESeBbXWo6DNzK2F0eIc80O0UQJSkTKf4RhMdpZixD WeVEQEMMUtp2+BrXe7id+CN2K3GQyksPPXoS6nF+sDfwbNIAibeqAwitn6eUwz8aNC+9 3JQUmXXSoAAgzqDfjw1Ho53YxR1tOfLL7TYLvJsUHVufJm5DrKGxRWu30HK23PEKOdtU g4QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=NHnDaep4soLIUVFgcK1vP1PkeHLaSM4DDjEPfhi0vRo=; b=iBtDWxdJPBNAMeUky2A3+R6PADkSg7JSrYqZ+uo27h/JUNViOron+WraU59bj2Td2d 51e71gsWKVGJCj/xt8p/HL5mCQrvk2MvwLGJeLCj2TlIaaFQ1tBTXoHug7dMw+svUMNO 3DyjgaZAZEzbCjyS1GvLwJLxOn7nu7DqYi/IucUADHiuRiEgRxNK/DBn8xANnG8JTiaA gx8uMcHpZh2UpeEmfsIp2oGSZ+1CtDM4cTBiDfkYtk9b1HKbqo+1OzyPHerbTfNNN7lW pGEpZshHWz/LqhL6MaTJPC4R6Tjfqkh2OrYogjRy6tgQxO8JmmFIO5iBOoFmarAYiumy fiJg== X-Gm-Message-State: AOAM531L8Il4O0ogWjvF4Q84Anccl9Fn7hawuRL5sdOiM3ZJ/16rBsUW Ffeb4BpuMCNYfO1FQH/XYHo= X-Received: by 2002:a05:620a:2f7:: with SMTP id a23mr12514148qko.256.1611781387947; Wed, 27 Jan 2021 13:03:07 -0800 (PST) Received: from localhost (dhcp-6c-ae-f6-dc-d8-61.cpe.echoes.net. [72.28.8.195]) by smtp.gmail.com with ESMTPSA id v12sm1983818qkg.63.2021.01.27.13.03.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Jan 2021 13:03:07 -0800 (PST) Sender: Tejun Heo Date: Wed, 27 Jan 2021 16:03:05 -0500 From: Tejun Heo To: Saravanan D Cc: x86@kernel.org, dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH V2] x86/mm: Tracking linear mapping split events Message-ID: References: <20210127175124.3289879-1-saravanand@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210127175124.3289879-1-saravanand@fb.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Wed, Jan 27, 2021 at 09:51:24AM -0800, Saravanan D wrote: > Numerous hugepage splits in the linear mapping would give > admins the signal to narrow down the sluggishness caused by TLB > miss/reload. > > To help with debugging, we introduce monotonic lifetime hugepage > split event counts since SYSTEM_RUNNING to be displayed as part of > /proc/vmstat in x86 servers > > The lifetime split event information will be displayed at the bottom of > /proc/vmstat > .... > swap_ra 0 > swap_ra_hit 0 > direct_map_2M_splits 139 > direct_map_4M_splits 0 > direct_map_1G_splits 7 > nr_unstable 0 > .... This looks great to me. > > Ancillary debugfs split event counts exported to userspace via read-write > endpoints : /sys/kernel/debug/x86/direct_map_[2M|4M|1G]_split > > dmesg log when user resets the debugfs split event count for > debugging > .... > [ 232.470531] debugfs 2M Pages split event count(128) reset to 0 > .... I'm not convinced this part is necessary or even beneficial. > One of the many lasting (as we don't coalesce back) sources for huge page > splits is tracing as the granular page attribute/permission changes would > force the kernel to split code segments mapped to huge pages to smaller > ones thereby increasing the probability of TLB miss/reload even after > tracing has been stopped. > > Signed-off-by: Saravanan D > --- > arch/x86/mm/pat/set_memory.c | 117 ++++++++++++++++++++++++++++++++++ > include/linux/vm_event_item.h | 8 +++ > mm/vmstat.c | 8 +++ > 3 files changed, 133 insertions(+) So, now the majority of the added code is to add debugfs knobs which don't provide anything that userland can't already do by simply reading the monotonic counters. Dave, are you still set on the resettable counters? Thanks. -- tejun