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 X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E0F0C433DF for ; Mon, 15 Jun 2020 11:25:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CE1822068E for ; Mon, 15 Jun 2020 11:25:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE1822068E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 351B66B0002; Mon, 15 Jun 2020 07:25:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DAF46B0003; Mon, 15 Jun 2020 07:25:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CA646B0005; Mon, 15 Jun 2020 07:25:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0232.hostedemail.com [216.40.44.232]) by kanga.kvack.org (Postfix) with ESMTP id 01A4F6B0002 for ; Mon, 15 Jun 2020 07:25:12 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B766A1EE6 for ; Mon, 15 Jun 2020 11:25:12 +0000 (UTC) X-FDA: 76931214864.03.drop60_010d50e26df6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 8C9C528A4E9 for ; Mon, 15 Jun 2020 11:25:12 +0000 (UTC) X-HE-Tag: drop60_010d50e26df6 X-Filterd-Recvd-Size: 4781 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Mon, 15 Jun 2020 11:25:11 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 6D267AECD; Mon, 15 Jun 2020 11:25:13 +0000 (UTC) Subject: Re: [PATCH v2] page_alloc: consider highatomic reserve in wmartermark fast To: Jaewon Kim Cc: Jaewon Kim , mgorman@techsingularity.net, minchan@kernel.org, mgorman@suse.de, hannes@cmpxchg.org, Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, ytk.lee@samsung.com, cmlaika.kim@samsung.com References: <20200613025102.12880-1-jaewon31.kim@samsung.com> From: Vlastimil Babka Message-ID: <62621a8b-5bdd-ed20-d816-5958ab07d44f@suse.cz> Date: Mon, 15 Jun 2020 13:25:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-Rspamd-Queue-Id: 8C9C528A4E9 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 Content-Transfer-Encoding: quoted-printable 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: On 6/13/20 6:16 AM, Jaewon Kim wrote: >=20 >=20 > 2020=EB=85=84 6=EC=9B=94 12=EC=9D=BC (=EA=B8=88) =EC=98=A4=ED=9B=84 11:= 34, Vlastimil Babka >=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: >> >> On 6/13/20 4:51 AM, Jaewon Kim wrote: >> > zone_watermark_fast was introduced by commit 48ee5f3696f6 ("mm, >> > page_alloc: shortcut watermark checks for order-0 pages"). The commi= t >> > simply checks if free pages is bigger than watermark without additio= nal >> > calculation such like reducing watermark. >> > >> > It considered free cma pages but it did not consider highatomic >> > reserved. This may incur exhaustion of free pages except high order >> > atomic free pages. >> > >> > Assume that reserved_highatomic pageblock is bigger than watermark m= in, >> > and there are only few free pages except high order atomic free. Bec= ause >> > zone_watermark_fast passes the allocation without considering high o= rder >> > atomic free, normal reclaimable allocation like GFP_HIGHUSER will >> > consume all the free pages. Then finally order-0 atomic allocation m= ay >> > fail on allocation. >> >> I don't understand why order-0 atomic allocation will fail. Is it beca= use of >> watermark check, or finding no suitable pages? >> - watermark check should be OK as atomic allocations can use reserves >> - suitable pages should be OK, even if all free pages are in the higha= tomic >> reserves, because rmqueue() contains: >> >> if (alloc_flags & ALLOC_HARDER) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 page =3D __rmqueue_smallest(zone, order, M= IGRATE_HIGHATOMIC); >> >> So what am I missing? >> > Hello > The order-0 atomic allocation can be failed because of=C2=A0depletion o= f suitable > free page. > Watermark check passes order-0 atomic allocation but it will be failed = at > finding a free page. > The=C2=A0 __rmqueue_smallest(zone, order, MIGRATE_HIGHATOMIC) can be us= ed > only for highorder. Ah, that's what I missed, rmqueue() will divert all order-0 allocations t= o rmqueue_pcplist() so those will not reach the hunk above. Thanks. >> > @@ -3598,9 +3604,12 @@ static inline bool zone_watermark_fast(struct= zone > *z, unsigned int order, >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Fast check for order-0 only. If th= is fails then the reserves >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* need to be calculated. There is a = corner case where the check >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* passes but only the high-order ato= mic reserve are free. If >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0* the caller is !atomic then it'll useles= sly search the free >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0* list. That corner case is then slower b= ut it is harmless. >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0*/ >> >> The comment stops being true after this patch? It also suggests that M= el >> anticipated this corner case, but that it should only cause a false po= sitive >> zone_watermark_fast() and then rmqueue() fails for !ALLOC_HARDER as it= cannot >> use MIGRATE_HIGHATOMIC blocks. It expects atomic order-0 still works. = So what's >> going on? >=20 > As Mel also agreed with me in v1 mail thread, this highatomic=C2=A0rese= rved should > be considered even in watermark fast. >=20 > The comment, I think, may need to be changed. Prior to this patch, non = highatomic > allocation may do useless search, but it also can take ALL non highatom= ic=C2=A0free. >=20 > With this patch, non highatomic=C2=A0allocation will NOT do useless sea= rch. Rather, Yes, that's what I meant.