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 62882C1975A for ; Thu, 12 Mar 2020 10:44:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 249C020716 for ; Thu, 12 Mar 2020 10:44:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=amazon.com header.i=@amazon.com header.b="VWA7Nib7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 249C020716 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 A80946B0003; Thu, 12 Mar 2020 06:44:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A32566B0006; Thu, 12 Mar 2020 06:44:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 947316B0007; Thu, 12 Mar 2020 06:44:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0187.hostedemail.com [216.40.44.187]) by kanga.kvack.org (Postfix) with ESMTP id 7CA0C6B0003 for ; Thu, 12 Mar 2020 06:44:34 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 4D832180AD822 for ; Thu, 12 Mar 2020 10:44:34 +0000 (UTC) X-FDA: 76586376468.24.eyes67_7f2bc1c1d1521 X-HE-Tag: eyes67_7f2bc1c1d1521 X-Filterd-Recvd-Size: 5434 Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Thu, 12 Mar 2020 10:44:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1584009874; x=1615545874; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=JjVUVkyITKh6OnXxlF9voS+7ECWo+oagHMISZeb68n4=; b=VWA7Nib7v5txFk4Ebznxsd5t/8sX3UDrHhinTW/VM3cXXKjmlvBBDAO1 sJgXHh6l1nm9HZWMc3ittp4WBzrzh02qJOu2JpSrmy8qzsEc3OIWnS4A+ KcPZu2JWLl4ZNtpyMfMT9MaQ4xKxcxnGLvxyKhD1i50AJQw9m5878r8Es k=; IronPort-SDR: /Fi5fDHbdGgFaeEVjGxuBCgt3uvjHvA06aECjECSM9gV2TCJT98Kim5T9TGOmaz7BBCuUl7Wyk oi8Pwii65PZA== X-IronPort-AV: E=Sophos;i="5.70,544,1574121600"; d="scan'208";a="20742458" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP; 12 Mar 2020 10:44:22 +0000 Received: from EX13MTAUEA002.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com (Postfix) with ESMTPS id E50F32820B7; Thu, 12 Mar 2020 10:44:19 +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.1236.3; Thu, 12 Mar 2020 10:44:19 +0000 Received: from u886c93fd17d25d.ant.amazon.com (10.43.162.47) by EX13D31EUA001.ant.amazon.com (10.43.165.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 12 Mar 2020 10:44:06 +0000 From: SeongJae Park To: SeongJae Park CC: Shakeel Butt , Andrew Morton , SeongJae Park , "Andrea Arcangeli" , Yang Shi , , , , , , Qian Cai , Colin Ian King , Jonathan Corbet , , , "Kirill A. Shutemov" , , Mel Gorman , Minchan Kim , Ingo Molnar , , , Randy Dunlap , David Rientjes , Steven Rostedt , , , "Vlastimil Babka" , Vladimir Davydov , Linux MM , , LKML Subject: Re: Re: Re: [PATCH v6 00/14] Introduce Data Access MONitor (DAMON) Date: Thu, 12 Mar 2020 11:43:45 +0100 Message-ID: <20200312104345.10032-1-sjpark@amazon.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200312100759.20502-1-sjpark@amazon.com> (raw) MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.43.162.47] X-ClientProxiedBy: EX13D16UWB001.ant.amazon.com (10.43.161.17) To EX13D31EUA001.ant.amazon.com (10.43.165.15) 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 Thu, 12 Mar 2020 11:07:59 +0100 SeongJae Park wrote: > On Tue, 10 Mar 2020 10:21:34 -0700 Shakeel Butt wrote: > > > On Mon, Feb 24, 2020 at 4:31 AM SeongJae Park wrote: > > > > > > From: SeongJae Park > > > > > > Introduction > > > ============ > > > [...] > > > > I do want to question the actual motivation of the design followed by this work. > > > > With the already present Page Idle Tracking feature in the kernel, I > > can envision that the region sampling and adaptive region adjustments > > can be done in the user space. Due to sampling, the additional > > overhead will be very small and configurable. > > > > Additionally the proposed mechanism has inherent assumption of the > > presence of spatial locality (for virtual memory) in the monitored > > processes which is very workload dependent. > > > > Given that the the same mechanism can be implemented in the user space > > within tolerable overhead and is workload dependent, why it should be > > done in the kernel? What exactly is the advantage of implementing this > > in kernel? > > First of all, DAMON is not for only user space processes, but also for kernel > space core mechanisms. Many of the core mechanisms will be able to use DAMON > for access pattern based optimizations, with light overhead and reasonable > accuracy. > > Implementing DAMON in user space is of course possible, but it will be > inefficient. Using it from kernel space would make no sense, and it would > incur unnecessarily frequent kernel-user context switches, which is very > expensive nowadays. Forgot mentioning about the spatial locality. Yes, it is workload dependant, but still pervasive in many case. Also, many core mechanisms in kernel such as read-ahead or LRU are already using some similar assumptions. If it is so problematic, you could set the maximum number of regions to the number of pages in the system so that each region monitors each page. Thanks, SeongJae Park > > > Thanks, > SeongJae Park > > > > > > thanks, > > Shakeel >