On 5/12/2014 10:04 AM, Laura Abbott wrote: > > I'm going to see about running this through tests internally for comparison. > Hopefully I'll get useful results in a day or so. > > Thanks, > Laura > We ran some tests internally and found that for our purposes these patches made the benchmarks worse vs. the existing implementation of using CMA first for some pages. These are mostly androidisms but androidisms that we care about for having a device be useful. The foreground memory headroom on the device was on average about 40 MB smaller when using these patches vs our existing implementation of something like solution #1. By foreground memory headroom we simply mean the amount of memory that the foreground application can allocate before it is killed by the Android Low Memory killer. We also found that when running a sequence of app launches these patches had more high priority app kills by the LMK and more alloc stalls. The test did a total of 500 hundred app launches (using 9 separate applications) The CMA memory in our system is rarely used by its client and is therefore available to the system most of the time. Test device - 4 CPUs - Android 4.4.2 - 512MB of RAM - 68 MB of CMA Results: Existing solution: Foreground headroom: 200MB Number of higher priority LMK kills (oom_score_adj < 529): 332 Number of alloc stalls: 607 Test patches: Foreground headroom: 160MB Number of higher priority LMK kills (oom_score_adj < 529): 459 Number of alloc stalls: 29538 We believe that the issues seen with these patches are the result of the LMK being more aggressive. The LMK will be more aggressive because it will ignore free CMA pages for unmovable allocations, and since most calls to the LMK are made by kswapd (which uses GFP_KERNEL) the LMK will mostly ignore free CMA pages. Because the LMK thresholds are higher than the zone watermarks, there will often be a lot of free CMA pages in the system when the LMK is called, which the LMK will usually ignore. Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>