Received: by 2002:a05:7412:b10a:b0:f3:1519:9f41 with SMTP id az10csp558800rdb; Thu, 30 Nov 2023 11:44:34 -0800 (PST) X-Google-Smtp-Source: AGHT+IEjlD2NudoWeClZoZ4fgniwXUU6ZbgZPE/2vLwX5NU+qrS7gUbPoqNZg/+Yx+4GTr/KUJlh X-Received: by 2002:a05:6a21:3291:b0:18b:3401:5c56 with SMTP id yt17-20020a056a21329100b0018b34015c56mr36368980pzb.22.1701373473957; Thu, 30 Nov 2023 11:44:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701373473; cv=none; d=google.com; s=arc-20160816; b=q/Uubi1CKj/t7X255YcFq0S8MMJA05RcDfB2QlCXhplRv8zXi9RTUu1yiLOaWWe1X1 wkaeoGkuqntourHwqk8WQiMf4VBmBheptpPpmJXQiBCSKGAXOk2/BhEhwHnd9STr3JO8 02il51ig0MOS7G3szLjTpPklg+S5bLnNw2YalQEEqBoN+WnVhzqmCOqJ6bNUNxHbU7EI RmUfL6fq6CpdlZX84+tvNkEESf9zh0CI9RHpgoFK+d2Mh9UC/go+BSlyccGKGLIY9inQ iVLNxOAmNB/Lkp8HihPFTeR5/XlC01o2cijjJgQyDOvWC//UH782HqJSgjj9EoXkU8if yDSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=U3RYUX/yot7BEqg2qxiSydsWLzUes1pFOIuMgweBXhI=; fh=UfQOkad9c7itxlc2aN206qkrnbaxAD6j72EGLuO7fjo=; b=VWc/iHiUI4KxNJqFwaZOjWCIbc2cQZQM5JfBUseWgazCXfzavOupZsbJEktiy8CzgA 8+T9DmO/hSR5l3ryNsisSRjeE6zrJvTQODgDwBEG+34r8IvP+g0DGQlskNgDZc3Ei4eS Rp8TrSHq+UskHl3AruZalYGJ7C1mIKaZjL8hdb4UdvaDo01mg+Q9s5OVAL9ErgSEMVU+ zr0b/3/4dEl6Z+b/3vSAVVlMRv6fdSoyEWR+ILUd1fJ6ndIIoHrfwSKzBXwz36YEwKKj JpIlmxjWBmOG3gwRvOeSNFFSEjnWa12GbUEFO5nXW8cPIlEZ1AUGUXsdzb6FXBxDy0T9 AdIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Vm24Fv+5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id y33-20020a634961000000b005b896ecd1efsi1986233pgk.172.2023.11.30.11.44.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Nov 2023 11:44:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Vm24Fv+5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 04FCA8026A3F; Thu, 30 Nov 2023 11:44:31 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376487AbjK3ToR (ORCPT + 99 others); Thu, 30 Nov 2023 14:44:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229746AbjK3ToQ (ORCPT ); Thu, 30 Nov 2023 14:44:16 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E6B8093 for ; Thu, 30 Nov 2023 11:44:22 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 01342C433C8; Thu, 30 Nov 2023 19:44:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701373462; bh=lVSnuH+tJnwYCxo7/cDHBwyalQ3cnS+JX2dNI0Wt3fU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Vm24Fv+5VtVQZ+asYdfwlm8/G5iS7aYut/0Ux8Yn9Y31WRBaIRPvFy+UdGBsuAf8z ZQOvQEKERgjTFSYUf/bV9Tba2TgcUB5jEO5HsDLT/uWw3ga5vXmAuRWpjH1kjO2vVD +n+UF4D52Ypo62Cks9iGFeeJNOA2M4iIvsqYcG6bJ9rMM40U2lNTI2qrWe1ZDDCnw9 ph/C8GFl7oXO37ivvdgR/fog4e8PrKf+r80OsDPqTervKsj2HKoUBH2upOmNadTl3C kFmX0UVrbnw8hcz1e8pF2zbWnFm8mY8DOcsSXHGw5OkEU2iDxX5I3VFS3ZNeiKNHX6 5W/2ump3Xrbjg== From: SeongJae Park To: cuiyangpei Cc: SeongJae Park , akpm@linux-foundation.org, damon@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, xiongping1@xiaomi.com Subject: Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature Date: Thu, 30 Nov 2023 19:44:20 +0000 Message-Id: <20231130194420.51355-1-sj@kernel.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231130091426.GA13946@cuiyangpei> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Thu, 30 Nov 2023 11:44:31 -0800 (PST) Hi Cuiyangpei, On Thu, 30 Nov 2023 17:14:26 +0800 cuiyangpei wrote: > Hi SeongJae, > > We also investigated the operation schemes you mentioned, but we don't > think it can fit our needs. > > On android, user will open many apps and switch between these apps as > needs. We hope to monitor apps' memory access only when they are on > foreground and record the memory access pattern when they are switched > to the background. > > When avaliable memory reaches a threshold, we will use these access > patterns with some strategies to recognize those memory that will have > little impact on user experience and to reclaim them proactively. > > I'm not sure I have clarified it clearly, if you still have questions > on this, please let us know. So, to my understanding, you expect applications may keep similar access pattern when they are in foreground, but have a different, less aggressive access pattern in background, and therefore reclaim memory based on the foreground-access pattern, right? Very interesting idea, thank you for sharing! Then, yes, I agree current DAMOS might not that helpful for the situation, and this record feature could be useful for your case. That said, do you really need full recording of the monitoring results? If not, DAMOS provides DAMOS tried regions feature[1], which allows users get the monitoring results snapshot that include both frequency and recency of all regions in an efficient way. If single snapshot is not having enough information for you, you could collect multiple snapshots. You mentioned absence of Python on Android as a blocker of DAMOS use on the previous reply[2], but DAMOS tried regions feature is not depend on tracepoints or Python. Of course, I think you might already surveyed it but found some problems. Could you please share that in detail if so? [1] https://docs.kernel.org/admin-guide/mm/damon/usage.html#schemes-n-tried-regions [2] https://lore.kernel.org/damon/20231129131315.GB12957@cuiyangpei/ Thanks, SJ > > Thanks.