From patchwork Tue May 19 09:58:04 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Charan Teja Kalla X-Patchwork-Id: 11557383 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 6AA14912 for ; Tue, 19 May 2020 09:58:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2D31F207FB for ; Tue, 19 May 2020 09:58:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="T2ONBU/Y" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2D31F207FB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 48EA5900003; Tue, 19 May 2020 05:58:28 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 43EB5900002; Tue, 19 May 2020 05:58:28 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 35424900003; Tue, 19 May 2020 05:58:28 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0216.hostedemail.com [216.40.44.216]) by kanga.kvack.org (Postfix) with ESMTP id 1802E900002 for ; Tue, 19 May 2020 05:58:28 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B9BE275B5 for ; Tue, 19 May 2020 09:58:27 +0000 (UTC) X-FDA: 76833018654.10.dolls64_2c613c5a8bc60 X-Spam-Summary: 2,0,0,6f63d7382c617b63,d41d8cd98f00b204,bounce+d06763.be9e4a-linux-mm=kvack.org@mg.codeaurora.org,,RULES_HIT:41:355:379:541:560:800:960:966:973:988:989:1260:1345:1437:1535:1543:1711:1730:1747:1777:1792:2196:2198:2199:2200:2393:2540:2559:2562:2693:2731:3138:3139:3140:3141:3142:3355:3865:3866:3867:3868:3870:3871:3872:3874:4385:4605:5007:6261:6630:6653:6691:7903:8603:8784:10004:11026:11218:11232:11473:11658:11914:12198:12296:12297:12517:12519:12555:13161:13229:14181:14394:14721:21080:21325:21451:21627:21972:30012:30054:30056,0,RBL:104.130.122.27:@mg.codeaurora.org:.lbl8.mailshell.net-64.201.201.201 62.14.0.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:ft,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:24,LUA_SUMMARY:none X-HE-Tag: dolls64_2c613c5a8bc60 X-Filterd-Recvd-Size: 5607 Received: from mail27.static.mailgun.info (mail27.static.mailgun.info [104.130.122.27]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Tue, 19 May 2020 09:58:24 +0000 (UTC) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1589882307; h=Message-Id: Date: Subject: Cc: To: From: Sender; bh=s+AdGI5XfKXn2vhFE20uM+6hS+slzQYyrhXIMBez0oU=; b=T2ONBU/YRcUr9yMKEQsKacXVA2AXR0s/hilVF72JBD3FAimMPueSgIRPV6K0oaF36CSxxd1Z 0K1KU7gTQyuFRWqh+AAKVFhRQiwoPubCdlAz2aTWTv8AaLtAI8BhbwIQ+trNRVr0s/m12Ncw 7BPu6Er4mnLEkIjddg3ukowD9Fw= X-Mailgun-Sending-Ip: 104.130.122.27 X-Mailgun-Sid: WyIwY2Q3OCIsICJsaW51eC1tbUBrdmFjay5vcmciLCAiYmU5ZTRhIl0= Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n05.prod.us-east-1.postgun.com with SMTP id 5ec3adb861db07dc42f981d2 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Tue, 19 May 2020 09:58:16 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 1C1FAC432C2; Tue, 19 May 2020 09:58:16 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.0 tests=ALL_TRUSTED,SPF_NONE, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from charante-linux.qualcomm.com (blr-c-bdr-fw-01_GlobalNAT_AllZones-Outside.qualcomm.com [103.229.19.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: charante) by smtp.codeaurora.org (Postfix) with ESMTPSA id 86DDDC433D2; Tue, 19 May 2020 09:58:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 86DDDC433D2 Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=none smtp.mailfrom=charante@codeaurora.org From: Charan Teja Reddy To: akpm@linux-foundation.org, linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, vinmenon@codeaurora.org, Charan Teja Reddy Subject: [PATCH] mm, page_alloc: skip ->waternark_boost for atomic order-0 allocations Date: Tue, 19 May 2020 15:28:04 +0530 Message-Id: <1589882284-21010-1-git-send-email-charante@codeaurora.org> X-Mailer: git-send-email 1.9.1 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: When boosting is enabled, it is observed that rate of atomic order-0 allocation failures are high due to the fact that free levels in the system are checked with ->watermark_boost offset. This is not a problem for sleepable allocations but for atomic allocations which looks like regression. This problem is seen frequently on system setup of Android kernel running on Snapdragon hardware with 4GB RAM size. When no extfrag event occurred in the system, ->watermark_boost factor is zero, thus the watermark configurations in the system are: _watermark = ( [WMARK_MIN] = 1272, --> ~5MB [WMARK_LOW] = 9067, --> ~36MB [WMARK_HIGH] = 9385), --> ~38MB watermark_boost = 0 After launching some memory hungry applications in Android which can cause extfrag events in the system to an extent that ->watermark_boost can be set to max i.e. default boost factor makes it to 150% of high watermark. _watermark = ( [WMARK_MIN] = 1272, --> ~5MB [WMARK_LOW] = 9067, --> ~36MB [WMARK_HIGH] = 9385), --> ~38MB watermark_boost = 14077, -->~57MB With default system configuration, for an atomic order-0 allocation to succeed, having free memory of ~2MB will suffice. But boosting makes the min_wmark to ~61MB thus for an atomic order-0 allocation to be successful system should have minimum of ~23MB of free memory(from calculations of zone_watermark_ok(), min = 3/4(min/2)). But failures are observed despite system is having ~20MB of free memory. In the testing, this is reproducible as early as first 300secs since boot and with furtherlowram configurations(<2GB) it is observed as early as first 150secs since boot. These failures can be avoided by excluding the ->watermark_boost in watermark caluculations for atomic order-0 allocations. Signed-off-by: Charan Teja Reddy --- mm/page_alloc.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index d001d61..5193d7e 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3709,6 +3709,18 @@ static bool zone_allows_reclaim(struct zone *local_zone, struct zone *zone) } mark = wmark_pages(zone, alloc_flags & ALLOC_WMARK_MASK); + /* + * Allow GFP_ATOMIC order-0 allocations to exclude the + * zone->watermark_boost in its watermark calculations. + * We rely on the ALLOC_ flags set for GFP_ATOMIC + * requests in gfp_to_alloc_flags() for this. Reason not to + * use the GFP_ATOMIC directly is that we want to fall back + * to slow path thus wake up kswapd. + */ + if (unlikely(!order && !(alloc_flags & ALLOC_WMARK_MASK) && + (alloc_flags & (ALLOC_HARDER | ALLOC_HIGH)))) { + mark = zone->_watermark[WMARK_MIN]; + } if (!zone_watermark_fast(zone, order, mark, ac->highest_zoneidx, alloc_flags)) { int ret;