Message ID | 20230621180454.973862-1-yuanchu@google.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp4568808vqr; Wed, 21 Jun 2023 11:44:45 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4vm3fX8UOuVuQfCJbcnoYHawqYR9GPQfpoLEvR+fRSqSTUqatoztN/LbduVJboqmZIkFu7 X-Received: by 2002:a05:6a20:d905:b0:11f:b831:c990 with SMTP id jd5-20020a056a20d90500b0011fb831c990mr7725537pzb.17.1687373085383; Wed, 21 Jun 2023 11:44:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687373085; cv=none; d=google.com; s=arc-20160816; b=yd2ZF2KvW9t2jCZyPjhzfUxm1mWdCatAaPbyijHxUwr1hkW+t5mlAp/xnSmuAneUc6 THlxayl3Ucn6n2YSj5He0lUnqUw0ZsKW7s/mRKBC5vVcOOm0MIm0+cD9bPCgjW+VKT1S 64Kme879S1yppF+vi2WCn3BhEp5MTFmqvssggn/H6mxfhI9DFEOxs4rKQGh3JiIY6WzK a6+4mFLnW7iCNRe3Ap/fBmNKIXMPznP0pw0r9msNyT0h+DoDKMPtBWq4kft/wPsOtJJ8 19ec5Q5niZdzggH46AaXhQpH3IQHFFVht4qq/XfgD4lBjs4vZbS4LeTYrCE4d0AbEhB6 jVrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=SErWj7qxRQBNUC6Smh628AB0v7WlXXsygGd167Tdi3o=; b=hB9o4g1rTUonhQGhh90oCTOdYeHruyBAOeupDR0/u+2nxhSf0rWTY4l4U3In7I2hOh 42pmTH7H/wxjkMPln/YIlINXuXw9MO623rMTpXaB315D6R6rvmXjCoQzG0H/+PzdFcN2 mwySJng5QbCvkMmGFl1lZxiTTRU5aM7ZmoYVWuNyjoLz3x2c9ziksNaQps57OXRjDaY5 Di6HEWVJx9DNGouT2rHt85i6Z7CdZADFDF1J8PaspZmRQlLGot4hx5f9LA+CJ+rUQdwp AQ4mjlXmkSRTyQPrMjmeSgQYFdYRd13WCk+IcvCKHzrAUa7EzCL5CHTptksXir+7izNd tUdA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=gH6qZbnm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z15-20020a63b90f000000b0054869ad741fsi4632213pge.877.2023.06.21.11.44.32; Wed, 21 Jun 2023 11:44:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=gH6qZbnm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231143AbjFUSRA (ORCPT <rfc822;maxin.john@gmail.com> + 99 others); Wed, 21 Jun 2023 14:17:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230036AbjFUSQ5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 21 Jun 2023 14:16:57 -0400 Received: from mail-pf1-x44a.google.com (mail-pf1-x44a.google.com [IPv6:2607:f8b0:4864:20::44a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 251A3107 for <linux-kernel@vger.kernel.org>; Wed, 21 Jun 2023 11:16:56 -0700 (PDT) Received: by mail-pf1-x44a.google.com with SMTP id d2e1a72fcca58-66663453f65so2980321b3a.0 for <linux-kernel@vger.kernel.org>; Wed, 21 Jun 2023 11:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687371415; x=1689963415; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=SErWj7qxRQBNUC6Smh628AB0v7WlXXsygGd167Tdi3o=; b=gH6qZbnmbvzhnYXoZHM0cADGdDaQIJB+Zb3K2J/nt0RJuILN8TTUQfNKhL1NoOpRoz 4eVB/B6O+ns16KrHXkmaeikTQ1b4ePaYZisr/NBGvmSQq0hmkMR56XmPQ9zVAPgyYpmv NWCVADLarekZTb/YF8tUjVsARrtG4eYeUd7AA+vBvQZiMqWNtFY3+HGIkyHzwljwaele W05jZa+gTCAsFM8uZ+8pwELeyZ6jb1Kp2qCG2b0T90gXpNA9TB2I4C8u3P2k6nyj8VqU jSnRcjmfT6h2C4RkMJHux+0cYzROGVEdGqr7gLxMMg1pIBqe2KL8660Qf2/lKBB+AAlN vztQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687371415; x=1689963415; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=SErWj7qxRQBNUC6Smh628AB0v7WlXXsygGd167Tdi3o=; b=RCKyv5NOq4/PpFFU/v8fd/skq52Iu8ao66h2KalsFYEAp2DU21+5CCFtUki1qHjAR8 5Uoj/4Co4j0Mypwsslx7QtFy6GgBzHbkn85lugJ9cRyg4rcMiTx4HYMBwGJkuqp8J7mn 0pWhHnRoP1WUq8VqL2vyGTnKzyKv2X95JPwaZh0sFnB+hoHPN9Q4PMiU7Nui8728bL90 9NK/pAAzicJy3aV6JYuNQYaTabNRrjlP0/Lq1In0rsrwxNHpui8bM7z21CLeE1INP3DH LFp9d5aNeZJXFEUOdnVugHabM3TmsZEzDUMP0/aHgsnHq+kW+O+HFZbsVH6V1185NrZW 2qKw== X-Gm-Message-State: AC+VfDxtG5I5s5N64cEW/dg4MHiscn/ogkbwWP97sack4f+HUy83L6oO ZJj+2v8nsHaIZgB1cpRpIM37RZmJLLsH X-Received: from yuanchu.c.googlers.com ([fda3:e722:ac3:cc00:24:72f4:c0a8:4024]) (user=yuanchu job=sendgmr) by 2002:a05:6a00:22c7:b0:666:e954:8ab6 with SMTP id f7-20020a056a0022c700b00666e9548ab6mr3973259pfj.3.1687371415509; Wed, 21 Jun 2023 11:16:55 -0700 (PDT) Date: Wed, 21 Jun 2023 18:04:48 +0000 Mime-Version: 1.0 X-Mailer: git-send-email 2.41.0.162.gfafddb0af9-goog Message-ID: <20230621180454.973862-1-yuanchu@google.com> Subject: [RFC PATCH v2 0/6] mm: working set reporting From: Yuanchu Xie <yuanchu@google.com> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J . Wysocki" <rafael@kernel.org>, "Michael S . Tsirkin" <mst@redhat.com>, David Hildenbrand <david@redhat.com>, Jason Wang <jasowang@redhat.com>, Andrew Morton <akpm@linux-foundation.org>, Johannes Weiner <hannes@cmpxchg.org>, Michal Hocko <mhocko@kernel.org>, Roman Gushchin <roman.gushchin@linux.dev>, Shakeel Butt <shakeelb@google.com>, Muchun Song <muchun.song@linux.dev>, Yu Zhao <yuzhao@google.com>, Kefeng Wang <wangkefeng.wang@huawei.com>, Kairui Song <kasong@tencent.com>, Yosry Ahmed <yosryahmed@google.com>, Yuanchu Xie <yuanchu@google.com>, "T . J . Alumbaugh" <talumbau@google.com> Cc: Wei Xu <weixugc@google.com>, SeongJae Park <sj@kernel.org>, Sudarshan Rajagopalan <quic_sudaraja@quicinc.com>, kai.huang@intel.com, hch@lst.de, jon@nutanix.com, Aneesh Kumar K V <aneesh.kumar@linux.ibm.com>, Matthew Wilcox <willy@infradead.org>, Vasily Averin <vasily.averin@linux.dev>, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-mm@kvack.org, cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769338920598498467?= X-GMAIL-MSGID: =?utf-8?q?1769338920598498467?= |
Series |
mm: working set reporting
|
|
Message
Yuanchu Xie
June 21, 2023, 6:04 p.m. UTC
RFC v1: https://lore.kernel.org/linux-mm/20230509185419.1088297-1-yuanchu@google.com/ For background and interfaces, see the RFC v1 posting. Changes from v1 -> v2: - Refactored the patchs into smaller pieces - Renamed interfaces and functions from wss to wsr (Working Set Reporting) - Fixed build errors when CONFIG_WSR is not set - Changed working_set_num_bins to u8 for virtio-balloon - Added support for per-NUMA node reporting for virtio-balloon The RFC adds CONFIG_WSR and requires MGLRU to function. T.J. and I aim to support the active/inactive LRU and working set estimation from the userspace as well. This series should be build with the following configs: CONFIG_LRU_GEN=y CONFIG_LRU_GEN_ENABLED=y CONFIG_VIRTIO_BALLOON=y CONFIG_WSR=y TODO list: - There's a hack in mm/vmscan.c that calls into the virtio-balloon driver, which doesn't work if CONFIG_VIRTIO_BALLOON=m. T.J. Alumbaugh (talumbau@google.com) and I plan on solving this problem with a working set notification mechanism that would allow multiple consumers to subscribe for working set changes. - memory.reaccess.histogram does not consider swapped out pages to be reaccessed. I plan to implement this with the shadow entry computed from mm/workingset.c. QEMU device implementation: https://lists.gnu.org/archive/html/qemu-devel/2023-05/msg06617.html virtio-dev spec proposal v1 (v2 to be posted by T.J.): https://lore.kernel.org/virtio-dev/CABmGT5Hv6Jd_F9EoQqVMDo4w5=7wJYmS4wwYDqXK3wov44Tf=w@mail.gmail.com/ LSF/MM discussion slides: https://lore.kernel.org/linux-mm/CABmGT5HK9xHz=E4q4sECCD8XodP9DUcH0dMeQ8kznUQB5HTQhQ@mail.gmail.com/ T.J. Alumbaugh (1): virtio-balloon: Add Working Set reporting Yuanchu Xie (5): mm: aggregate working set information into histograms mm: add working set refresh threshold to rate-limit aggregation mm: report working set when under memory pressure mm: extend working set reporting to memcgs mm: add per-memcg reaccess histogram drivers/base/node.c | 3 + drivers/virtio/virtio_balloon.c | 288 +++++++++++++++++ include/linux/balloon_compaction.h | 3 + include/linux/memcontrol.h | 6 + include/linux/mmzone.h | 5 + include/linux/wsr.h | 114 +++++++ include/uapi/linux/virtio_balloon.h | 33 ++ mm/Kconfig | 7 + mm/Makefile | 1 + mm/internal.h | 12 + mm/memcontrol.c | 351 ++++++++++++++++++++- mm/mmzone.c | 3 + mm/vmscan.c | 194 +++++++++++- mm/wsr.c | 464 ++++++++++++++++++++++++++++ 14 files changed, 1480 insertions(+), 4 deletions(-) create mode 100644 include/linux/wsr.h create mode 100644 mm/wsr.c
Comments
On Wed, Jun 21, 2023 at 12:16 PM Yuanchu Xie <yuanchu@google.com> wrote: > > RFC v1: https://lore.kernel.org/linux-mm/20230509185419.1088297-1-yuanchu@google.com/ > For background and interfaces, see the RFC v1 posting. v1 only mentioned one use case (ballooning), but we both know there are at least two solid use cases (the other being job scheduling/binpacking, e.g., for kubernetes [1]). Please do a survey, as thoroughly as possible, of use cases. * What's the significance of WSR to the landscape, in terms of server and client use cases? * How would userspace tools, e.g., a PMU-based memory profiler, leverage the infra provided by WSR? * Would those who register slab shrinkers, e.g., DMA buffs [2], want to report their working sets? * Does this effort intersect with memory placement with NUMA and CXL.mem? [1] https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ [2] https://lore.kernel.org/linux-mm/20230123191728.2928839-1-tjmercier@google.com/