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 0C075FA373E for ; Tue, 25 Oct 2022 20:54:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A67528E0002; Tue, 25 Oct 2022 16:54:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A17A88E0001; Tue, 25 Oct 2022 16:54:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8DFAB8E0002; Tue, 25 Oct 2022 16:54:04 -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 801298E0001 for ; Tue, 25 Oct 2022 16:54:04 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2EF33120282 for ; Tue, 25 Oct 2022 20:54:04 +0000 (UTC) X-FDA: 80060674008.24.42EE529 Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) by imf16.hostedemail.com (Postfix) with ESMTP id C178F180032 for ; Tue, 25 Oct 2022 20:54:02 +0000 (UTC) Received: by mail-qk1-f171.google.com with SMTP id m6so9082140qkm.4 for ; Tue, 25 Oct 2022 13:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=8cbuu5NxrLuy+svcRghiXil0f9HUvsQIk72bu4jMYG0=; b=J7oWN5+rNPq33bmmHP5KEOMXl99soMVw2neA4Bjv19KOiAeW/wKkl3SZui8GfmUacj qQdcYwUbuesOi+tRJEkId6Zknra792Kf8Pg3McitI3MSthmwHPur6ycMdEtgW8QySHxk +duMwRHzxReQvx+ndLxXCI5RfvI1pfFVwLP2PquAPzEaisCVhMQYJI6K/lUzwS6uPR2N OhI7yZplqYw3/hypYqbnzsnMD4GLPQICijaQXAkx4L1sGfEBIPrdaU9Ey8PCVFZguyLK wV9eF+sEUWmvB7i3nsmEgK6VJCbmTB/Y4OuTtMpKYbtxlw5LDl8/BVNCkotu9dLbK35f mBMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8cbuu5NxrLuy+svcRghiXil0f9HUvsQIk72bu4jMYG0=; b=RURP59TRexP4/++ppEOibwLosxIFM1Y/9hqu9sJKlNBToutFK+GNvshxEDN1ovDJiO HkWAfjWVqbFyF4i3ibsei9gpFPZIqYbqDV/7mNGprmi4j7qN1NS203vjYd+kIGmOXXJ0 AFO9wssEdpl94i3FIeo7xWCqjYPTSMYuSf/htAcMeiYSQRdMfIOKR2liEfHk74nLw0VC 9mX1Rm4wjCqXvC1AIOH7HYtrIJ5IH8N7XE6M6Z3ls2GbLFSvLod/6WOWVKDY29b2LMCw fTJNJD1bi6gfwL/o7FaJrd1MFRYWUl4y6DBWZqBmCSZrOx9EHFPeg8DlvZJVmtHaiQs6 u4CA== X-Gm-Message-State: ACrzQf3AhlXs8o4Cb1VnA42kK84Uilhk+oFO0BMt/k2yJ82mDQNd3Jmp 0dBj/5vX5eMBIgagHFO1jK9e1pVHD1uwkg== X-Google-Smtp-Source: AMsMyM5nC8dAql4TQBE1Wo3rbAM+LONk6LKK8ae00dBX1b75ncbsYyxtlcd/I7py55A8AI1bLa3RVg== X-Received: by 2002:a37:e118:0:b0:6ec:565e:f2d8 with SMTP id c24-20020a37e118000000b006ec565ef2d8mr28510136qkm.719.1666731241918; Tue, 25 Oct 2022 13:54:01 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::25f1]) by smtp.gmail.com with ESMTPSA id y19-20020a05620a25d300b006ec62032d3dsm2714776qko.30.2022.10.25.13.54.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Oct 2022 13:54:01 -0700 (PDT) Date: Tue, 25 Oct 2022 16:54:02 -0400 From: Johannes Weiner To: Yang Shi Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Eric Bergen Subject: Re: [PATCH] mm: vmscan: split khugepaged stats from direct reclaim stats Message-ID: References: <20221025170519.314511-1-hannes@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666731243; a=rsa-sha256; cv=none; b=VChIvOxcSPGe12qmG02nGzhqDha358iC1svz1X7WF0t6bjrT+ltLhe7WTjE7BT0ZT+eaKg czaDTPA2rQY09bsXzr27reDrKscm30mvErWl+qRwzkePRBrRiurOpgXryXcoRciXihBkJ2 8T0cYsNOLbTHfG7jqJHiFpdnHrOFPBg= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=J7oWN5+r; spf=pass (imf16.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.171 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666731243; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8cbuu5NxrLuy+svcRghiXil0f9HUvsQIk72bu4jMYG0=; b=N1TZrRANwQfZvcdECJ24vuMbNSD2D3QPGTDlBNc5ndOpXSJx5+3NDfgd2WT9/N8QbgQjQl Zp8Aly/WGGd7uDafamtssR3Sj8SQ9uFAa7p4Ewr2Y+oMO+1mdYSGSI2RIoSXtoLvOjR8q3 RDVcxTHK4c8Zg/LDwHEPUuF+wZc2s+c= X-Rspam-User: X-Rspamd-Queue-Id: C178F180032 Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=J7oWN5+r; spf=pass (imf16.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.171 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org X-Stat-Signature: nnixye7nbjuhr3t8m566xp5z1st7n1qe X-Rspamd-Server: rspam03 X-HE-Tag: 1666731242-355353 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: On Tue, Oct 25, 2022 at 12:40:15PM -0700, Yang Shi wrote: > On Tue, Oct 25, 2022 at 10:05 AM Johannes Weiner wrote: > > > > Direct reclaim stats are useful for identifying a potential source for > > application latency, as well as spotting issues with kswapd. However, > > khugepaged currently distorts the picture: as a kernel thread it > > doesn't impose allocation latencies on userspace, and it explicitly > > opts out of kswapd reclaim. Its activity showing up in the direct > > reclaim stats is misleading. Counting it as kswapd reclaim could also > > cause confusion when trying to understand actual kswapd behavior. > > > > Break out khugepaged from the direct reclaim counters into new > > pgsteal_khugepaged, pgdemote_khugepaged, pgscan_khugepaged counters. > > > > Test with a huge executable (CONFIG_READ_ONLY_THP_FOR_FS): > > > > pgsteal_kswapd 1342185 > > pgsteal_direct 0 > > pgsteal_khugepaged 3623 > > pgscan_kswapd 1345025 > > pgscan_direct 0 > > pgscan_khugepaged 3623 > > There are other kernel threads or works may allocate memory then > trigger memory reclaim, there may be similar problems for them and > someone may try to add a new stat. So how's about we make the stats > more general, for example, call it "pg{steal|scan}_kthread"? I'm not convinved that's a good idea. Can you generally say that userspace isn't indirectly waiting for one of those allocating threads? With khugepaged, we know. And those other allocations are usually ___GFP_KSWAPD_RECLAIM, so if they do direct reclaim, we'd probably want to know that kswapd is failing to keep up (doubly so if userspace is waiting). In a shared kthread counter, khugepaged would again muddy the waters.