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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34D9DC433F5 for ; Thu, 7 Oct 2021 16:34:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A5D38610A1 for ; Thu, 7 Oct 2021 16:34:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A5D38610A1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 14B606B006C; Thu, 7 Oct 2021 12:34:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FD2F6B0071; Thu, 7 Oct 2021 12:34:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDCFB6B0072; Thu, 7 Oct 2021 12:34:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0038.hostedemail.com [216.40.44.38]) by kanga.kvack.org (Postfix) with ESMTP id DB6956B006C for ; Thu, 7 Oct 2021 12:34:12 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8E83F39B84 for ; Thu, 7 Oct 2021 16:34:12 +0000 (UTC) X-FDA: 78670188744.06.68B8AA2 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf26.hostedemail.com (Postfix) with ESMTP id 28ECB200B3AA for ; Thu, 7 Oct 2021 16:34:12 +0000 (UTC) Received: by mail-qt1-f178.google.com with SMTP id z24so1998237qtv.9 for ; Thu, 07 Oct 2021 09:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=ui3Zht7gk020J4pnZHjyE2xEVPI8NlCg4DvxTFIksaQ=; b=1u1fP++bIB8g/1iWAgTT4y0zbnmRczgrcXrF+1kS6GjmFXj7dpGgZNbPoBqbnT0jxZ K+glsN/IWwiByn1dSFEQK+4QZW96M1R3VDqzeRSxOOwb4PqruuYLqkcsK5x3gwbTP6LY hVfmUOBsw73mwXVlnMINQIp7Pauw+Nh+busFGamOWWHZnGkxn+WzQWGfxrb7mH2jMHe9 vV5Xd4sLHHVAPzPETxgR6L8cBVrfZf+q4f4/TGF/hwOHywILZh3881iJsClE9FAj9H5K S/12cjKcY66ktd64n122qziHo0944XVgOmXpvaLG6Gj3sbi+vKH3fGAGpl2ktMmJGnHq i9Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=ui3Zht7gk020J4pnZHjyE2xEVPI8NlCg4DvxTFIksaQ=; b=z9qLYVAmbXc/iIr9GML53xOe4cvKJmZ9PIuEINp6S3m/61UpLn7HkZNWNqMrF/Vf5l VdP6LDCbBUR8ob5cPRUWEz2L/h318e+N8EeU2Ln7hdbEXHFol+qv8YYHpooFi6yKNbmE WAcouUaCCUvaNX51zqbjg3e++bDkHlDZBHMDqyTtGgJLqK03rNUY1W+FFQ/yRgQ2ku30 W2cP921L35DjIVyEOTP2cM9UZ4mQwzFFxaDFN2bFZb+1+AtlFnlCKodDzsgT+ZAA1ULH WpCbFZwXnhRwW104IGdNviOtY5FRRk1as5UIkxqMPbmg9n3S5d0IIikBi3ym7m6qaEtW YO3A== X-Gm-Message-State: AOAM5330dTGDo5hvDkVnVg3ii4GRJI8I3u2jp7oiJmuaAeskFiyuSjab KHZTg+lB2WHhpLaWr8xnTi4/6w== X-Google-Smtp-Source: ABdhPJxbnXn8H2eKBBwL5e2NXuHeekoXVevUbMZNR49f39CXPSHyhOeuLu+F5HLEMEePvTK3bCL2Og== X-Received: by 2002:a05:622a:1712:: with SMTP id h18mr6106228qtk.389.1633624451319; Thu, 07 Oct 2021 09:34:11 -0700 (PDT) Received: from localhost (cpe-98-15-154-102.hvc.res.rr.com. [98.15.154.102]) by smtp.gmail.com with ESMTPSA id a3sm6871qkh.67.2021.10.07.09.34.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Oct 2021 09:34:08 -0700 (PDT) Date: Thu, 7 Oct 2021 12:34:06 -0400 From: Johannes Weiner To: =?utf-8?B?6KejIOWSj+aihQ==?= Cc: "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Subject: Re: =?utf-8?B?5Zue5aSNOiDlm57lpI06IFtQQVRD?= =?utf-8?Q?H=5D_mm=3Avmscan=3A_fix_extra_adjustmen?= =?utf-8?Q?t?= for lruvec's nonresident_age in case of reactivation Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 28ECB200B3AA X-Stat-Signature: x7ynqtcpxe47zx4jsxxbdjkxg5afm73e Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=1u1fP++b; spf=pass (imf26.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.178 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org X-HE-Tag: 1633624452-31153 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.001343, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hello Yongmei, On Thu, Oct 07, 2021 at 02:35:44PM +0000, =E8=A7=A3 =E5=92=8F=E6=A2=85 wr= ote: > You're right. I checked with the commit 264e90cc07f177adec17ee7cc154dda= a132f0b2d >=20 > I was say that, because back to 1 or 2 years ago, VM used reclaim_stat'= s rotation/scan as the factor to balance the ratio between fs page cache = and anonymous pages. > It used the side effect of working set activation (it raised rotation c= ount) to challenge the other side memory: file vs anon > And in shrink_active_list deactivation also contributes to rotation cou= nt. >=20 > So I got the conclusion that active list rotation refers to deactivatio= n. > I checked with commit #264e90c, only executable code section contribute= s to active list rotation. Thank you for pointing out my misunderstanding= . > But, deactivation contributes to PGROTATED event. I'm still a sort of c= onfused:( Yeah PGROTATED is a little strange! I'm not sure people use it much. > 1 more question: > why activation/deativation/deactive_fn removes the contribution to lru = cost? because those are cpu intensive not I/O intensive, right? >=20 > So for now, if we'd like to balance the ratio between fs page cache and= anonymous pages, we only take I/O (in allocation path and reclaim path) = into consideration. Yes, correct. The idea is to have the algorithm serve the workingset with the least amount of paging IO. Actually, the first version of the patch accounted for CPU overhead, since anon and file do have different aging rules with different CPU requirements. However, it didn't seem to matter in my testing, and it's a bit awkward to compare IO cost and CPU cost since it depends heavily on the underlying hardware, so I deleted that code. It's possible we may need to add it back if a workload shows up that cares. > As my observation, VM don't take fs periodical dirty flush as I/O cost. Correct. The thinking is: writeback IO needs to happen with or without reclaim, because of data integrity. Whereas swapping only happens under memory pressure - without anon reclaim we would not do any swap writes. Of course, reclaim can trigger accelerated dirty flushing, which *could* result in increased IO and thus higher LRU cost: two buffered writes to the same page within the dirty expiration window would result in one disk write but could result in two under pressure. It's a pain to track this properly, though, so the compromise is that when kswapd gets in enough trouble that it needs to flush pages one by one (NR_VMSCAN_WRITE). This seems to work reasonably well in practice. > Looking forward to your reply! >=20 > Thanks again. I get more clear view of VM:) >=20 >=20 > It is Chinese national holiday, sorry for my late response. Happy Golden Week! Johannes