Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp4511538ioa; Wed, 27 Apr 2022 05:32:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzNzPEltdvWQx5GUkdrfxRRGy8FP2w6jXoY9UErb6lJ76xr8Aomj1Eklk8HwFniDttidLRY X-Received: by 2002:a17:90b:1c07:b0:1d9:6360:307 with SMTP id oc7-20020a17090b1c0700b001d963600307mr19000970pjb.182.1651062753717; Wed, 27 Apr 2022 05:32:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651062753; cv=none; d=google.com; s=arc-20160816; b=deFh6S0c0x0/VVNPMPVJBCB3Tf+76gSSP8UyEUm/9fAEpo51o49gXQ+Ym9VV8QzJxd CbSqMPtUeFdIrDQkh2Ye17bflTIJ3vuEm8StesiwzkCtn0Rz8cY7dkWJSDBTvdhAkW8m cNSu6KwL9CWwqsmudB/M5icGCob1UCLSXQCXXo1IRQq1UW2I3S1ou85RpiAPqtax+gE9 Fi1pB1LnCrFs3bCceHin/xxAxFK+X3dcm8vPEUYVNrzNfr1LWH7bfA2Fetto6xykYbzo n/jRdImveTw8o5OAbSxsnFJtUxQhJHqhYfB401Ys0lZpr1NhqWzP1lv4hgVqi6kpmbJQ 4pIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=dmo4NJ9OnZ4Y4aH664FqTlPCiSRdEsYxgel7MlG6SAE=; b=0jJZ6kPbZmEyFKOgwSaRAroCfHOmxbqrZ8nbeiO5imjtEaA9uQhrbuLXEU5d0kqR7v hvjUCrzQKNXzk7XSFoaVu8iBFNNxRClP4HQv8Zt+GsXNk3ND1B5p96FoTeuvG3Pra+Bt Dkt48VKkWbkDGlZPasw4mghug6/ptC/GgU5FrK9sr5LZ/OoP5udPcLUMCU+liLWfS9uu 9VWspEFXNSCUYH86QoJLwOGdAHrYngPvVpS0ZyWhmHI5ePccn57dSDRKIWnnZGNJvati TaPyKSttmykqLUxzP7DeQchrSvXZz3tXCs+YKAIWoWQ41pv1+DfLq4UCxebRT7NA6bvp cFjA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id i17-20020a6561b1000000b003a56645cf96si1341438pgv.335.2022.04.27.05.32.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 05:32:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6C96654FBB; Wed, 27 Apr 2022 05:07:00 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233554AbiD0MKA (ORCPT + 99 others); Wed, 27 Apr 2022 08:10:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36144 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233534AbiD0MJ5 (ORCPT ); Wed, 27 Apr 2022 08:09:57 -0400 Received: from out30-57.freemail.mail.aliyun.com (out30-57.freemail.mail.aliyun.com [115.124.30.57]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D96736C943 for ; Wed, 27 Apr 2022 05:06:42 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R131e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04426;MF=rongwei.wang@linux.alibaba.com;NM=1;PH=DS;RN=17;SR=0;TI=SMTPD_---0VBTdM9p_1651061196; Received: from 30.240.99.9(mailfrom:rongwei.wang@linux.alibaba.com fp:SMTPD_---0VBTdM9p_1651061196) by smtp.aliyun-inc.com(127.0.0.1); Wed, 27 Apr 2022 20:06:38 +0800 Message-ID: <0042ba8f-d432-008c-4a2d-0d3ea03fb38c@linux.alibaba.com> Date: Wed, 27 Apr 2022 20:06:36 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:100.0) Gecko/20100101 Thunderbird/100.0 Subject: Re: DAMON VA regions don't split on an large Android APP Content-Language: en-US To: Barry Song <21cnbao@gmail.com> Cc: sj@kernel.org, Andrew Morton , Linux-MM , LKML , Matthew Wilcox , shuah@kernel.org, brendanhiggins@google.com, foersleo@amazon.de, sieberf@amazon.com, Shakeel Butt , sjpark@amazon.de, tuhailong@gmail.com, Song Jiang , =?UTF-8?B?5byg6K+X5piOKFNpbW9uIFpoYW5nKQ==?= , =?UTF-8?B?5p2O5Z+56ZSLKHdpbmsp?= , xhao@linux.alibaba.com References: From: Rongwei Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,UNPARSEABLE_RELAY 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: X-Mailing-List: linux-kernel@vger.kernel.org On 4/27/22 3:44 PM, Barry Song wrote: > On Wed, Apr 27, 2022 at 6:56 PM Rongwei Wang > wrote: >> >> >> >> On 4/27/22 7:19 AM, Barry Song wrote: >>> Hi SeongJae & Andrew, >>> (also Cc-ed main damon developers) >>> On an Android phone, I tried to use the DAMON vaddr monitor and found >>> that vaddr regions don't split well on large Android Apps though >>> everything works well on native Apps. >>> >>> I have tried the below two cases on an Android phone with 12GB memory >>> and snapdragon 888 CPU. >>> 1. a native program with small memory working set as below, >>> #define size (1024*1024*100) >>> main() >>> { >>> volatile int *p = malloc(size); >>> memset(p, 0x55, size); >>> >>> while(1) { >>> int i; >>> for (i = 0; i < size / 4; i++) >>> (void)*(p + i); >>> usleep(1000); >>> >>> for (i = 0; i < size / 16; i++) >>> (void)*(p + i); >>> usleep(1000); >>> >>> } >>> } >>> For this application, the Damon vaddr monitor works very well. >>> I have modified monitor.py in the damo userspace tool a little bit to >>> show the raw data getting from the kernel. >>> Regions can split decently on this kind of applications, a typical raw >>> data is as below, >>> >>> monitoring_start: 2.224 s >>> monitoring_end: 2.329 s >>> monitoring_duration: 104.336 ms >>> target_id: 0 >>> nr_regions: 24 >>> 005fb37b2000-005fb734a000( 59.594 MiB): 0 >>> 005fb734a000-005fbaf95000( 60.293 MiB): 0 >>> 005fbaf95000-005fbec0b000( 60.461 MiB): 0 >>> 005fbec0b000-005fc2910000( 61.020 MiB): 0 >>> 005fc2910000-005fc6769000( 62.348 MiB): 0 >>> 005fc6769000-005fca33f000( 59.836 MiB): 0 >>> 005fca33f000-005fcdc8b000( 57.297 MiB): 0 >>> 005fcdc8b000-005fd115a000( 52.809 MiB): 0 >>> 005fd115a000-005fd45bd000( 52.387 MiB): 0 >>> 007661c59000-007661ee4000( 2.543 MiB): 2 >>> 007661ee4000-0076623e4000( 5.000 MiB): 3 >>> 0076623e4000-007662837000( 4.324 MiB): 2 >>> 007662837000-0076630f1000( 8.727 MiB): 3 >>> 0076630f1000-007663494000( 3.637 MiB): 2 >>> 007663494000-007663753000( 2.746 MiB): 1 >>> 007663753000-007664251000( 10.992 MiB): 3 >>> 007664251000-0076666fd000( 36.672 MiB): 2 >>> 0076666fd000-007666e73000( 7.461 MiB): 1 >>> 007666e73000-007667c89000( 14.086 MiB): 2 >>> 007667c89000-007667f97000( 3.055 MiB): 0 >>> 007667f97000-007668112000( 1.480 MiB): 1 >>> 007668112000-00766820f000(1012.000 KiB): 0 >>> 007ff27b7000-007ff27d6000( 124.000 KiB): 0 >>> 007ff27d6000-007ff27d8000( 8.000 KiB): 8 >>> >>> 2. a large Android app like Asphalt 9 >>> For this case, basically regions can't split very well, but monitor >>> works on small vma: >>> >>> monitoring_start: 2.220 s >>> monitoring_end: 2.318 s >>> monitoring_duration: 98.576 ms >>> target_id: 0 >>> nr_regions: 15 >>> 000012c00000-0001c301e000( 6.754 GiB): 0 >>> 0001c301e000-000371b6c000( 6.730 GiB): 0 >>> 000371b6c000-000400000000( 2.223 GiB): 0 >>> 005c6759d000-005c675a2000( 20.000 KiB): 0 >>> 005c675a2000-005c675a3000( 4.000 KiB): 3 >>> 005c675a3000-005c675a7000( 16.000 KiB): 0 >>> 0072f1e14000-0074928d4000( 6.510 GiB): 0 >>> 0074928d4000-00763c71f000( 6.655 GiB): 0 >>> 00763c71f000-0077e863e000( 6.687 GiB): 0 >>> 0077e863e000-00798e214000( 6.590 GiB): 0 >>> 00798e214000-007b0e48a000( 6.002 GiB): 0 >>> 007b0e48a000-007c62f00000( 5.323 GiB): 0 >>> 007c62f00000-007defb19000( 6.199 GiB): 0 >>> 007defb19000-007f794ef000( 6.150 GiB): 0 >>> 007f794ef000-007fe8f53000( 1.745 GiB): 0 >>> >>> As you can see, we have some regions which are very very big and they >>> are losing the chance to be splitted. But >>> Damon can still monitor memory access for those small VMA areas very well like: >>> 005c675a2000-005c675a3000( 4.000 KiB): 3 >> Hi, Barry >> >> Actually, we also had found the same problem in redis by ourselves >> tool[1]. The DAMON can not split the large anon VMA well, and the anon >> VMA has 10G~20G memory. I guess the whole region doesn't have sufficient >> hot areas to been monitored or found by DAMON, likes one or more address >> choose by DAMON not been accessed during sample period. > > Hi Rongwei, > Thanks for your comments and thanks for sharing your tools. > > I guess the cause might be: > in case a region is very big like 10GiB, we have only 1MiB hot pages > in this large region. > damon will randomly pick one page to sample, but the page has only > 1MiB/10GiB, thus > less than 1/10000 chance to hit the hot 1MiB. so probably we need > 10000 sample periods > to hit the hot 1MiB in order to split this large region? > > @SeongJae, please correct me if I am wrong. > >> >> I'm not sure whether sets init_regions can deal with the above problem, >> or dynamic choose one or limited number VMA to monitor. >> > > I won't set a limited number of VMA as this will make the damon too hard to use > as nobody wants to make such complex operations, especially an Android > app might have more than 8000 VMAs. > > I agree init_regions might be the right place to enhance the situation. > >> I'm not sure, just share my idea. >> >> [1] https://github.com/aliyun/data-profile-tools.git > > I suppose this tool is based on damon? How do you finally resolve the problem Yes, and we plan to design it to be a user agent. > that large anon VMAs can't be splitted? I see your have different environment with mine. Finally, I just monitor the anon VMA and set a large regions number. There is one or two large anon VMAs in my environment. It seems different with your. > Anyway, I will give your tool a try. > >>> >>> Typical characteristics of a large Android app is that it has >>> thousands of vma and very large virtual address spaces: >>> ~/damo # pmap 2550 | wc -l >>> 8522 >>> >>> ~/damo # pmap 2550 >>> ... >>> 0000007992bbe000 4K r---- [ anon ] >>> 0000007992bbf000 24K rw--- [ anon ] >>> 0000007fe8753000 4K ----- [ anon ] >>> 0000007fe8754000 8188K rw--- [ stack ] >>> total 36742112K >>> >>> Because the whole vma list is too long, I have put the list here for >>> you to download: >>> wget http://www.linuxep.com/patches/android-app-vmas >>> >>> I can reproduce this problem on other Apps like youtube as well. >>> I suppose we need to boost the algorithm of splitting regions for this >>> kind of application. >>> Any thoughts? >>> > > Thanks > Barry