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 X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E878C433E0 for ; Tue, 9 Jun 2020 09:18:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 468AA207ED for ; Tue, 9 Jun 2020 09:18:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=amazon.com header.i=@amazon.com header.b="FdC6sM1S" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 468AA207ED Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=amazon.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D43AC6B0006; Tue, 9 Jun 2020 05:18:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CF4FC6B0007; Tue, 9 Jun 2020 05:18:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE3506B0008; Tue, 9 Jun 2020 05:18:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0052.hostedemail.com [216.40.44.52]) by kanga.kvack.org (Postfix) with ESMTP id A3AF76B0006 for ; Tue, 9 Jun 2020 05:18:15 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 4CB661813C160 for ; Tue, 9 Jun 2020 09:18:15 +0000 (UTC) X-FDA: 76909122150.13.stick28_1a1633826dc1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id 1833D18129D68 for ; Tue, 9 Jun 2020 09:18:15 +0000 (UTC) X-HE-Tag: stick28_1a1633826dc1 X-Filterd-Recvd-Size: 6897 Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Tue, 9 Jun 2020 09:18:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1591694294; x=1623230294; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=exl4vfoj+rVOj20nvUHMYvhRB2IgKdPBd3fOicc2tBA=; b=FdC6sM1Sxa3f71KZPewLuY9Eh3ssJs5w8H3Zfxw0u4CualUK4E55H+fU lVo6gfv2mQ3zvMVHstwQtIgSkqpMoVdB+nMADfiZ/892bfbN3tfJ1IOXV 6w2BRxpjeaYIND33FUCvzD6i9Zp+mA16YlhQMdTggz3/V/ED49orUpcC3 Y=; IronPort-SDR: l7FgCOW1uOUOCBtlDuJ60BwlAl1BMk1XDTlOgDe0mrU6MYyPQvHMiwZ4w5L6qf0rqq6uGQBUfj hd23/eTF6bgg== X-IronPort-AV: E=Sophos;i="5.73,491,1583193600"; d="scan'208";a="42604495" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1e-17c49630.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 09 Jun 2020 09:18:09 +0000 Received: from EX13MTAUEA002.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-17c49630.us-east-1.amazon.com (Postfix) with ESMTPS id 22187A044E; Tue, 9 Jun 2020 09:17:58 +0000 (UTC) Received: from EX13D31EUA001.ant.amazon.com (10.43.165.15) by EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 9 Jun 2020 09:17:57 +0000 Received: from u886c93fd17d25d.ant.amazon.com (10.43.162.248) by EX13D31EUA001.ant.amazon.com (10.43.165.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 9 Jun 2020 09:17:41 +0000 From: SeongJae Park To: David Hildenbrand CC: SeongJae Park , , "SeongJae Park" , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: Re: [RFC v11 3/8] mm/damon: Implement data access monitoring-based operation schemes Date: Tue, 9 Jun 2020 11:17:25 +0200 Message-ID: <20200609091725.15859-1-sjpark@amazon.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: (raw) MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.43.162.248] X-ClientProxiedBy: EX13D04UWA004.ant.amazon.com (10.43.160.234) To EX13D31EUA001.ant.amazon.com (10.43.165.15) X-Rspamd-Queue-Id: 1833D18129D68 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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, 9 Jun 2020 10:47:45 +0200 David Hildenbrand wrote: > On 09.06.20 08:53, SeongJae Park wrote: > > From: SeongJae Park > > > > In many cases, users might use DAMON for simple data access aware > > memory management optimizations such as applying an operation scheme to > > a memory region of a specific size having a specific access frequency > > for a specific time. For example, "page out a memory region larger than > > 100 MiB but having a low access frequency more than 10 minutes", or "Use > > THP for a memory region larger than 2 MiB having a high access frequency > > for more than 2 seconds". > > > > To minimize users from spending their time for implementation of such > > simple data access monitoring-based operation schemes, this commit makes > > DAMON to handle such schemes directly. With this commit, users can > > simply specify their desired schemes to DAMON. > > What would be the alternative? How would a solution where these policies > are handled by user space (or inside an application?) look like? Most simple form of the altermative solution would be doing offline data access pattern profiling using DAMON and modifying the application source code or system configuration based on the profiling results. More automated alternative solution would be a daemon constructed with two modules: - monitor: monitors the data access pattern of the workload via the DAMON debugfs interface - memory manager: based on the monitoring result, make appropriate memory management changes via mlock(), madvise(), sysctl, etc. The daemon would be able to run inside the application process as a thread, or outside as a standalone process. If the daemon could not run inside the application process, the memory management changes it could make would be further limited, though, as mlock() and madvise() would not be available. The madvise_process(), which is already merged in the next tree, would be helpful in this case. > > > > Each of the schemes is composed with conditions for filtering of the > > target memory regions and desired memory management action for the > > target. Specifically, the format is:: > > > > > > > > The filtering conditions are size of memory region, number of accesses > > to the region monitored by DAMON, and the age of the region. The age of > > region is incremented periodically but reset when its addresses or > > access frequency has significantly changed or the action of a scheme was > > applied. For the action, current implementation supports only a few of > > madvise() hints, ``MADV_WILLNEED``, ``MADV_COLD``, ``MADV_PAGEOUT``, > > ``MADV_HUGEPAGE``, and ``MADV_NOHUGEPAGE``. > > I am missing some important information. Is this specified for *all* > user space processes? Or how is this configured? What are examples? > > E.g., messing with ``MADV_HUGEPAGE`` vs. ``MADV_NOHUGEPAGE`` of random > applications can change the behavior/break these applications. (e.g., if > userfaultfd is getting used and the applciation explicitly sets > MADV_NOHUGEPAGE). Only monitoring target processes will be applied. The monitoring target processes can be specified by writing the process ids to 'pids' debugfs file or constructing the 'struct damon_ctx' via the programming interface. I will refine the commit message to make the points clearer, in the next spin. [...] > > > -- > Thanks, > > David / dhildenb