OpenHarmony 3.2 内存查杀配置说明

仓库主页及介绍 https://gitee.com/openharmony/resourceschedule_memmgr

配置文件

文件位置

配置文件位于代码的foundation/resourceschedule/memmgr/profile/memmgr_config.xml

位于设备的/etc/memmgr/memmgr_config.xml

替换

修改好memmgr_config.xml后，将其推到设备的/etc/memmgr/下并重启即可：

hdc shell mount -o remount,rw /
hdc file send 本地文件路径 /etc/memmgr/memmgr_config.xml
hdc shell reboot

应用优先级

优先级列表可以查看https://gitee.com/openharmony/resourceschedule_memmgr#%E8%BF%9B%E7%A8%8B%E5%9B%9E%E6%94%B6%E4%BC%98%E5%85%88%E7%BA%A7%E5%88%97%E8%A1%A8

优先级数值越低，被系统回收或查杀的概率越低。-1000为系统进程，无论如何都不会被查杀。-800在极端情况下会被查杀，400则在内存达到一定的阈值一定会被查杀。

修改应用优先级

0-400的优先级由系统决定，无法定制，应用只能被修改为普通应用或常驻应用(-800)，当应用被配置为常驻进程后，不会在运行时再被修改为0-400。修改应用为常驻进程的有两种方式：

memmgr_config.xml

在memmgr_config.xml文件中，增加killableSysApp节点，值为应用的bundle name，如下：

<Memmgr>
  ...
  <reclaimPriorityConfig>
    <killalbeSystemApps>
      <killableSysApp>com.ohos.launcher</killableSysApp>
    </killalbeSystemApps>
  </reclaimPriorityConfig>
  ...
</Memmgr>

install_list_capability.json

该配置文件位于厂商vendor目录内，如对于RK3568，其位于vender/hihope/rk3568/preinstall-config/install_list_capability.json。可参考SystemUI应用配置keepAlive和singleton属性为true:

{
     "bundleName": "com.ohos.systemui",
     "singleton": true,
     "keepAlive": true,
     "runningResourcesApply": false,
     "app_signature" : ["8E93863FC32EE238060BF69A9B37E2608FFFB21F93C862DD511CBAC9F30024B5"],
     "associatedWakeUp": false,
     "allowAppUsePrivilegeExtension": true
}

其中singleton配置为true后，应用将所属于0号用户，而非100号普通用户，应用数据不会与账户关联。

keepAlive配置为true后，应用被杀死后会被系统重新拉起，且singleton也为true时，会在开机自启动。

使用场景

两者都能修改应用优先级为-800，但是memmgr_config.xml方式不影响应用的启动与运行，而install_list_capability.json方式适合重要的系统服务。

可用buffer

buffer指标用来衡量当前系统资源提供内存的能力，内存回收与查杀均基于系统的可用buffer，当前系统的了用buffer可通过如下命令查看：

# cat /dev/memcg/memory.zswapd_pressure_show
buffer_size:1351
recent_refault:0

其中buffer_size即为可用buffer，单位为MB。计算公式：free pages + (活跃文件页 * active_file_ratio / 100) + (非活跃文件页 * inactive_file_ratio / 100)。

active_file_ratio与inactive_file_ratio可通过如下查看：

# cat /dev/memcg/memory.buffer_ratio_params
inactive_file_ratio: 90
active_file_ratio: 70

也可参考：

# cat /proc/zoneinfo
Node 0, zone      DMA
  per-node stats
      nr_inactive_anon 75504
      nr_active_anon 95
      nr_inactive_file 71869
      nr_active_file 17263
      nr_inactive_purgeable 0
      nr_active_purgeable 0
      nr_unevictable 6550
      nr_slab_reclaimable 12957
      nr_slab_unreclaimable 16140
      nr_isolated_anon 0
      nr_isolated_file 0
      workingset_nodes 0
      workingset_refault_anon 0
      workingset_refault_file 0
      workingset_activate_anon 0
      workingset_activate_file 0
      workingset_restore_anon 0
      workingset_restore_file 0
      workingset_nodereclaim 0
      nr_anon_pages 75561
      nr_mapped    58056
      nr_file_pages 95721
      nr_dirty     75
      nr_writeback 0
      nr_writeback_temp 0
      nr_shmem     6606
      nr_shmem_hugepages 0
      nr_shmem_pmdmapped 0
      nr_file_hugepages 0
      nr_file_pmdmapped 0
      nr_anon_transparent_hugepages 0
      nr_vmscan_write 0
      nr_vmscan_immediate_reclaim 0
      nr_dirtied   9792
      nr_written   7136
      nr_kernel_misc_reclaimable 0
      nr_foll_pin_acquired 0
      nr_foll_pin_released 0
      nr_kernel_stack 18368
  pages free     268308
        min      2560
        low      3200
        high     3840
        spanned  523776
        present  519680
        managed  500550
        protection: (0, 0, 0, 0)
      nr_free_pages 268308
      nr_zone_inactive_anon 75504
      nr_zone_active_anon 95
      nr_zone_inactive_file 71869
      nr_zone_active_file 17263
      nr_zone_inactive_purgeable 0
      nr_zone_active_purgeable 0
      nr_zone_unevictable 6550
      nr_zone_write_pending 75
      nr_mlock     0
      nr_page_table_pages 1925
      nr_bounce    0
      nr_zspages   3
      nr_free_cma  0
      nr_skb_pages 0
  pagesets
    cpu: 0
              count: 340
              high:  378
              batch: 63
  vm stats threshold: 30
    cpu: 1
              count: 343
              high:  378
              batch: 63
  vm stats threshold: 30
    cpu: 2
              count: 431
              high:  378
              batch: 63
  vm stats threshold: 30
    cpu: 3
              count: 335
              high:  378
              batch: 63
  vm stats threshold: 30
  node_unreclaimable:  0
  start_pfn:           512
Node 0, zone    DMA32
  pages free     0
        min      0
        low      0
        high     0
        spanned  0
        present  0
        managed  0
        protection: (0, 0, 0, 0)
Node 0, zone   Normal
  pages free     0
        min      0
        low      0
        high     0
        spanned  0
        present  0
        managed  0
        protection: (0, 0, 0, 0)
Node 0, zone  Movable
  pages free     0
        min      0
        low      0
        high     0
        spanned  0
        present  0
        managed  0
        protection: (0, 0, 0, 0)

其中：

• nr_free_pages为公式中的free pages

• nr_zone_active_file为公式中的活跃文件页

• nr_zone_inactive_file为公式中的非活跃文件页

具体实现可以参考kernel/linux/linux-5.10/mm/zswapd.c

内存查杀

触发时机

内存查杀的触发时机与回收不同，系统会通过PSI监听系统当前压力，如果在任何1秒的时间窗口内，一个或多个进程因为分配内存而造成的时间停顿超过了阈值10ms时，将会触发内存查杀，即向/proc/pressure/memory写入：

<some 10000 1000000>

配置说明

<Memmgr>
  <killConfig>
      <killLevel id="1">
          <memoryMB>250</memoryMB>
          <minPriority>400</minPriority>
      </killLevel>
      <killLevel id="2">
          <memoryMB>180</memoryMB>
          <minPriority>300</minPriority>
      </killLevel>
      <killLevel id="3">
          <memoryMB>120</memoryMB>
          <minPriority>200</minPriority>
      </killLevel>
      <killLevel id="4">
          <memoryMB>75</memoryMB>
          <minPriority>100</minPriority>
      </killLevel>
      <killLevel id="5">
          <memoryMB>50memoryMB>
          <minPriority>0</minPriority>
      </killLevel>
  </killConfig>
</Memmgr>

上述配置意味着：

1. 当可用buffer大于180M小于250M时，开始查杀优先级为400的进程。

2. 当可用buffer大于120M小于180M时，开始查杀优先级为300及400的进程，优先查杀400。

3. 当可用buffer大于75M小于120M时，开始查杀优先级为200及以上的进程，优先查杀400。

4. 以此类推

如果应用的优先级不同，优先级的值越大，越优先查杀。如果应用的优先级相同，默认情况下，uid越大的应用，越容易被查杀。

查杀流程

1. 当触发查杀后，从优先级列表拿一个可被kill的进程

2. 尝试kill进程

3. kill后查询可用buffer，如果buffer小于250M，即killConfig中最大的那一条配置，则继续查杀，重复步骤1

优先级列表规则

在应用优先级相同的情况下，uid越大的应用，越容易被查杀。uid在应用安装后不会变动，越晚安装的应用uid越大。一般情况下Launcher与Settings的uid比较大。这样容易造成一种情况：

后台有多个应用，同时内存不足了，那么每次被查杀的总是那几个uid比较大的应用。

修改默认规则

我们可能需要修改这种规则，但是目前没有配置文件可以修改，只能通过修改代码实现。代码位于：foundation/resourceschedule/memmgr/services/memmgrservice/include/reclaim_priority_manager/reclaim_priority_manager.h

struct BundleInfoPtrCmp {
        bool operator() (const std::shared_ptr<BundlePriorityInfo> p1, const std::shared_ptr<BundlePriorityInfo> p2)
        {
            if (p1->uid_ == p2->uid_) {
                // remove duplicate BundlePriorityInfo according to uid_
                return false;
            } else {
                if (p1->priority_ != p2->priority_) {
                    // in ascending order
                    return p1->priority_ < p2->priority_;
                } else {
                    // when in same priority_, sort by uid_
                    // it will be sorted by last used time
                    return p1->uid_ < p2->uid_;
                }
            }
        }
    };

其他配置

systemMemoryLevelConfig

<Memmgr>
  <systemMemoryLevelConfig>
      <moderate>800</moderate>
      <low>700</low>
      <critical>600</critical>
  </systemMemoryLevelConfig>
</Memmgr>

改配置与查杀的触发时机一致，并且会对比系统可用内存与配置中的值，并通过AppMgr调用应用的OnMemoryLevel函数供应用处理。