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 AD07CC46467 for ; Thu, 12 Jan 2023 01:50:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 220608E0002; Wed, 11 Jan 2023 20:50:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D09B8E0001; Wed, 11 Jan 2023 20:50:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 098B48E0002; Wed, 11 Jan 2023 20:50:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id EA9418E0001 for ; Wed, 11 Jan 2023 20:50:15 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id AF92C40669 for ; Thu, 12 Jan 2023 01:50:15 +0000 (UTC) X-FDA: 80344466790.25.B5BD72C Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) by imf16.hostedemail.com (Postfix) with ESMTP id 3662C18000C for ; Thu, 12 Jan 2023 01:50:14 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=iX6gRZV8; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of yuanchu@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=yuanchu@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673488214; 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=UI4K5mRi88yph1Y15SVIzngc8V0hAChiN1WwnseNjSo=; b=KkoYwtdnrGFARaghWswtphTngvhiFVUVzlDtOELpcgzT9u4+EFybZhaDKrDFxsIaHSWUbO 6MA4fMqXkHGmZt3JuoyYKbqWhr+FRocDFLiGQKTOrgcvCbk3+BDNq/mobkrFR4XksHryuX iU/xQB98MIgrKQ5+i3GRBXzXbYWeeuY= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=iX6gRZV8; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of yuanchu@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=yuanchu@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673488214; a=rsa-sha256; cv=none; b=46BF4bH1O4+py1Hy6OVfTwtduWU0COSR8amysAIfwggZFa2dNUkFE2LEKBzqMqJL4fuLSG D2lctUH1/iSVDEtfNakkSURqXgVnDY0UKf6JY5x0XGyzdSZLOXA+NVa0iZYlalw5EW4SFd zzEhFLnOzJRv47Y8IJknFt5/D46SjEY= Received: by mail-yb1-f171.google.com with SMTP id t15so17106125ybq.4 for ; Wed, 11 Jan 2023 17:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UI4K5mRi88yph1Y15SVIzngc8V0hAChiN1WwnseNjSo=; b=iX6gRZV8sICaehqfIKKCsTSZN1Qto1VW/o+R0dPGvkB24JZnDkCpMXaGC1UFCMCDAc 65kuNToXIj4iXR4wXhLwWIDCeYuJgxjaQ/q+do9MI07FludH6aZA3vLr/9IkjsITho1/ ZgBV3Si+v22hTmbdtckw6PN7PpNig1Dew2+7PUya3A5kMFGyHhvVHfD+DbOlVm71omPW 1SwwzDe4Gs6f0NzLBZ+IIXwOGRD9kSi2XJe8Qd8ijsWWpakPWge0tVjudFgQAW3GGS2R cIJHdBLnBJ4GCsGFjMH/J/n5H+PMYqXtd3GCNGPPiJ91I14Hcy8XzkCIj2evn8CIcQit LY4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=UI4K5mRi88yph1Y15SVIzngc8V0hAChiN1WwnseNjSo=; b=RlHN+zp4HlC32R84Pg6ovUnIGXbm9QHs0U6pYWRP/+56t3NGg/Co1mK0MxvaKHWwg3 LMPqIG7oViz/dZf/AmNPIHCS3AaCKSYP+tqfxnwxfLRtq0yx5CJh3dYMAyv+WPmhYVzT REXYkmaNJQSh6GK57FMvTbfuf1Ji9uujPPkexPYR+1hpoazbgdhZ+04AS9Vq/Z2fI7oU 4e/b9XRfb/NiGW1k7K9Qo5kCmPXYBqTCyvjWcfIiidj1rnqQ/fNfkDWMeRN0WzXR1xmI AG1mID9BXoV+inb54Ukbs9TNMZWFDp248/QdnlYogOpy6iP3/QZOf/5s+NGf9VGAEdsg 1rVQ== X-Gm-Message-State: AFqh2kqRbwcocpmdW3OyapQhE/AWi9wTf5RkYlQM7EOUlRH32XKN4fgc SW8i5pUh5e7MiglaeoYaSGG/X2v024BdIakyT38uvA== X-Google-Smtp-Source: AMrXdXu/Y0MEDSF578Eq5uQrp+u9YsYRd5gi/5tB92Rl2gsQ8XI50SHWRT2nN4aSvKOmApC1fGnZGXoNSW+oWAaF+AM= X-Received: by 2002:a05:6902:1029:b0:77d:eb9f:1381 with SMTP id x9-20020a056902102900b0077deb9f1381mr7180187ybt.475.1673488213106; Wed, 11 Jan 2023 17:50:13 -0800 (PST) MIME-Version: 1.0 References: <20221214225123.2770216-1-yuanchu@google.com> <87k01ulxdd.fsf@linux.ibm.com> In-Reply-To: <87k01ulxdd.fsf@linux.ibm.com> From: Yuanchu Xie Date: Wed, 11 Jan 2023 17:50:02 -0800 Message-ID: Subject: Re: [RFC PATCH 0/2] mm: multi-gen LRU: working set extensions To: "Aneesh Kumar K.V" Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Yu Zhao , Andrew Morton , Shakeel Butt , Muchun Song , linux-kernel@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 3662C18000C X-Stat-Signature: ckp7pcb5iie8ebwkgxmaq98p81dz3yps X-HE-Tag: 1673488214-247824 X-HE-Meta: U2FsdGVkX19RNYY6fJ2ihyPHJvIHSGQQsSoAk0gWMKgWLQ83TI2Ok2AM/Ys468v3zXwhO1fMCLVVKqSuw9xGGWsnrz2YEpjzkrF4izM8f7vHCy+VM/CyriUjNwTU35f5LdBcsddjEpUH6zEYsCtMYKi/bd5//KhdNTaq+DyZkDlW4znWmft+vsCjzeZSOd8zViB04LgNBQMMJYRg04YsQEiSTqsc9d1cKhtj8m1zJP9EXaEujCM+qV30RvPlX0yZWIbTwIQztqwzEM55075tFh7weIXxRIiXxFvxNfbb7aLBQbwKqbjTtN2HK8JIqoVIFS3QXO9IewY5Q6VGNQp+8mPjR0zWfh+TQ6nVQJERKIEoQmrcJipjBE6JFUQB63wh8zFZm/xq3B66W1mm5ileRnFwGdnaFj13fULKDTbu5UGFMoEoROUN1ufpw7pMLDJlW2kuUDzoNxtrIEXFUalNslTP7Dhaot58U4nhhpTKBM4OXBY+74p8sRdLNGPKltei1rtQPht9aCYc7YHck25Sc1aTNwKY4h8xKNgV+xrt2OfywLN3YChdCF5VR4uDZASx+so0kaB/oNOppz3lGpRYf3eyMsuY+RnU31Nkgoysras7rpTxyMG6+c7ofZTLePmRXZ29PU62RYP5qbBp9+NbI5AFs5Y2X8QzzTFr/BKjKtY8Ph8ENXZeKMkSNzYfF21aJs67ZuXks6j6wUKSjsZA1nTjriLof9Ho2/bKjHoxuUGz3cYc90bUlLwAR9bBrIIIQKCAe3umuxad38bLCoacI/urhPzpXTK65Dk6gCPCfU8kTKhPHdCWg3BvpOhzXT7BLMSdFPlsu16FOma2I0jp3N01MOQQohRjmhmkfRSLOAkGuRnAAZMz9DPdpUEmigRLekcM+9L5NT5Os4LzmD3iQPR0Zi96CA/q7S5qM6ygYCybqnihJN18BcinB0FZJ9/NofbUfkhdQeP9AbbgVII uWoFP9hd U9flWokhOeTHbNX8= 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 Mon, Jan 9, 2023 at 10:25 PM Aneesh Kumar K.V wrote: > > Yuanchu Xie writes: > > > Introduce a way of monitoring the working set of a workload, per page > > type and per NUMA node, with granularity in minutes. It has page-level > > granularity and minimal memory overhead by building on the > > Multi-generational LRU framework, which already has most of the > > infrastructure and is just missing a useful interface. > > > > MGLRU organizes pages in generations, where an older generation contains > > colder pages, and aging promotes the recently used pages into the young > > generation and creates a new one. The working set size is how much > > memory an application needs to keep working, the amount of "hot" memory > > that's frequently used. The only missing pieces between MGLRU > > generations and working set estimation are a consistent aging cadence > > and an interface; we introduce the two additions. > > So with kold kthread do we need aging in reclaim ? Should we switch reciam > to wakeup up kold kthread to do aging instead of doing try_to_inc_max_seq? > This would also help us to try different aging mechanism which can run > better in a kthread. If I understand correctly, MGLRU tries to put off aging as much as possible for reclaim, and prefers aging uniformly in kswapd, so that already sort of happens. With periodic aging on, reclaim only triggers aging when it reclaims memory less than (MIN_NR_GENS * aging_interval) cold.