Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp4408552ioa; Wed, 27 Apr 2022 03:15:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJynPztBvwE2/gyueoSDXeCdzVvKld7v/WyP1smdfyBI08mHowYQ2HmI5BIqQdmUMbMcwG22 X-Received: by 2002:a17:90a:62c7:b0:1da:2c51:943e with SMTP id k7-20020a17090a62c700b001da2c51943emr3954344pjs.208.1651054528529; Wed, 27 Apr 2022 03:15:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651054528; cv=none; d=google.com; s=arc-20160816; b=SEScfvuhHMhZ5wrLtJlJI8vTGkhM2So5CyFP8/xE60c71GQv7N2yclSzrRa56/1O11 Wbe/s1Tr3htIK27WiKkbw5PuCadXkLYIwGLdub4Rz26E73jxiArhe6NvK3JrU+26twcs dJS9s/KFroGXczObjqFGlLkbn/yUonaKrnFONLAWeRl/pjw0lEtqnrgaoQx1/AdY73aI mWKM5p3T/VCRW2s1ejuxytb80v7HOWfNbfJK3QtO8PXM6U1InibV4IFjZWi8FF1MS3oU xaoBG2gzeU8Xe7bNGt77AX0afBV6ctBh7wf/ErBxG+p1PG1rJOtu5MfPuG19xDgKeCgB fh1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:mime-version :dkim-signature; bh=I12FseGpNZFjVRmn5cSNRW69oiEmtDZ/uG4cngFYR/E=; b=koLOSwWxzhipO3rV+GXq6tnnv8h0uh1B4rbik7GuXuw/EctSWJKwYsPaii3nenCvPs R1esz2wx2jOVZBTeux3uLhxK/KFgEUUMOGeOJRkCKxaT8r7/KDT2jpJCrXi+KdUtk3DH hgXRxbQk/Jzn/GkzN0zv97a3QIcIA6Rd4+EZ+RdOg1S93bioDfQkES8pL6XLQHlSMIeK WiHF38wNXaCYQX3BPf2+zTll5bX9C2Juw6lN9zFuBHXMU+2Tb6m/YtbRm8/2RTCe/eel jb8TlhIxLUjJZ5fPw7mrxLi/6zZswmpBS0SAKrCYiHmjDh9KYWerYVZZxyCr5SPfXKpk jf3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Tzq1jYp4; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id e17-20020a056a001a9100b0050d476df702si982306pfv.167.2022.04.27.03.15.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 03:15:28 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Tzq1jYp4; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 2F6F733825E; Wed, 27 Apr 2022 02:36:48 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353553AbiDZXWq (ORCPT + 99 others); Tue, 26 Apr 2022 19:22:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242199AbiDZXWp (ORCPT ); Tue, 26 Apr 2022 19:22:45 -0400 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DFF982FFEC for ; Tue, 26 Apr 2022 16:19:35 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id d6so36616ede.8 for ; Tue, 26 Apr 2022 16:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=I12FseGpNZFjVRmn5cSNRW69oiEmtDZ/uG4cngFYR/E=; b=Tzq1jYp4wkcTjMZv0yfDaecsq7guRfTN1LOyoH5fwLQXplSvz4cqbIV0fpfLsdmSSf nPyfjXDwES9SKAaisER0zCniR91iHngrGAnFsU6OfLKHLzn4Ex6Y5ZFHZLb0oCoEIxln oR1KihGGEWbnC4pv9KeLdcJCz82xXLL/VQwUiFZdNB0CMzKILGGco5fUBY50qJqfFPaL aLibHVvHsLjoXBqbvdQiBRX7nUuj87fh+C553AoJ++6ITz/9asKKAOHLEJOQgA9ZSVXX H+ENhvDMUqTdVTmTKUB43LgIP7eU04AL0rgvAUdmO6PPbW3JIwt6pAdtva7Pli4zvESC /P0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=I12FseGpNZFjVRmn5cSNRW69oiEmtDZ/uG4cngFYR/E=; b=h2mVvy+BdxZeatvHQQSqXxLaAQ+rH6j8n7jKdULKxq7Ixp+kc9SEw4AVXUHig3NBch u0BsfAFeYMZQbJKmaw/+ZPZKvipzMyYqQcDaM+VqHhR6esN6EamG59Kkz1V2Gkv1bKMI 8T78vg4uFAM9BdI/Upsc/xg4dlnOTcq8XHYvPaZ0e6kH3kmNU/ihLP+hOsnuu2PNKKxW JckjY9TYa5Ypg7NnpSU4mx1Z0MQAlHh9CH9ju0bt56KxYH2lG+VVgyhCEcp8dce9yR83 ayEZM4mNiTkI8m/+8QKQLxVGidmKJgkn4jSB2Eq5hJLEWMYx1uWXEAgEd9A5kA4joP+G eiLA== X-Gm-Message-State: AOAM531gq/PhveutTm9+u2u14zPEVNcZCes9SMX+oRcGYuEGFlYOwraT JTFj3bLlrAem5fCVzKFYnLsdqRX/Nfc2ZtG5MHM= X-Received: by 2002:a05:6402:5106:b0:425:f733:8d9b with SMTP id m6-20020a056402510600b00425f7338d9bmr8451468edd.326.1651015174287; Tue, 26 Apr 2022 16:19:34 -0700 (PDT) MIME-Version: 1.0 From: Barry Song <21cnbao@gmail.com> Date: Wed, 27 Apr 2022 11:19:23 +1200 Message-ID: Subject: DAMON VA regions don't split on an large Android APP To: sj@kernel.org, Andrew Morton , Linux-MM , LKML Cc: 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?= Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE autolearn=no 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 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 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