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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4793C433F5 for ; Tue, 26 Apr 2022 23:19:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6171E6B0073; Tue, 26 Apr 2022 19:19:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C6146B0075; Tue, 26 Apr 2022 19:19:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 467E26B0078; Tue, 26 Apr 2022 19:19:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 36C176B0073 for ; Tue, 26 Apr 2022 19:19:36 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1745B21142 for ; Tue, 26 Apr 2022 23:19:36 +0000 (UTC) X-FDA: 79400599152.07.E2B3F61 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf05.hostedemail.com (Postfix) with ESMTP id F0B91100056 for ; Tue, 26 Apr 2022 23:19:28 +0000 (UTC) Received: by mail-ed1-f52.google.com with SMTP id e23so24606eda.11 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=OKbi0RBt7+HlhfwrgemNFTOXAEtOcMe9F2gzsS6vCAzOTr34S53Vf4gQjwWSnzFRPK b+17CV6nqL2BBQS8zf4uopGdLT4EoQ+K506T2mVejOJjPbAlwSqHPY82MY2EkBEAj8m+ y1ou+oFg06NaRqB4zHUXQIN4l0qF5/HSBeuWbJHwB49128mmanEZfGABd5a94eIlpiKe XFWQ6BKTv5YJFbZij+kdr7NYluwk4AHjuRf7Z9J+nMiHwmeqrn2hG0a/kHWVP/ZSUL3g vbAv/X5ZjNfPuniHqkni3je1xKAqZi6kjxBLnQCcEW8AzJgrM8XImPVorcstpF0QiFbv 9LaQ== X-Gm-Message-State: AOAM531LLDv2XxIVJcU0oXRcz0BjvLU+E9Q9GXJ8Zrmi4Yy++gCy+jrB sVOcueqea+hIQitI/8OugNEHYvmJ2vSz6g9qu4U= X-Google-Smtp-Source: ABdhPJxqAHHEcStmtW0maUvW8wuhWOtediVX49nG357iKpxU0MDdLlQ4wVKoPMGgAnPfl4yg9aFZBPO9peiHr9je63g= 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-Stat-Signature: is1jioxwets3zm81odcphbjfo6yubiqc X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: F0B91100056 Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Tzq1jYp4; spf=pass (imf05.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-HE-Tag: 1651015168-525352 X-Bogosity: Ham, tests=bogofilter, spamicity=0.171078, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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