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 70BD1ECAAD8 for ; Tue, 20 Sep 2022 11:02:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D97A4940009; Tue, 20 Sep 2022 07:02:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D487A940007; Tue, 20 Sep 2022 07:02:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C376A940009; Tue, 20 Sep 2022 07:02:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B7308940007 for ; Tue, 20 Sep 2022 07:02:25 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 94EBD4023E for ; Tue, 20 Sep 2022 11:02:25 +0000 (UTC) X-FDA: 79932175050.20.2B7808F Received: from outbound-smtp44.blacknight.com (outbound-smtp44.blacknight.com [46.22.136.52]) by imf29.hostedemail.com (Postfix) with ESMTP id 17ED0120011 for ; Tue, 20 Sep 2022 11:02:23 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail05.blacknight.ie [81.17.254.26]) by outbound-smtp44.blacknight.com (Postfix) with ESMTPS id E0855F80BF for ; Tue, 20 Sep 2022 12:02:22 +0100 (IST) Received: (qmail 27686 invoked from network); 20 Sep 2022 11:02:22 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 20 Sep 2022 11:02:22 -0000 Date: Tue, 20 Sep 2022 12:02:18 +0100 From: Mel Gorman To: Zhenhua Huang Cc: Michal Hocko , akpm@linux-foundation.org, vbabka@suse.cz, linux-mm@kvack.org, quic_tingweiz@quicinc.com Subject: Re: [RESEND PATCH] mm:page_alloc.c: lower the order requirement of should_reclaim_retry Message-ID: <20220920110218.oegqcgvrscwecgtz@techsingularity.net> References: <1663556455-30188-1-git-send-email-quic_zhenhuah@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf29.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.136.52 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663671744; a=rsa-sha256; cv=none; b=ZoGqh5zz5SPz21KNy4G2kHB8vc17U6D9LN06neWblMJSataKZjHj+9OwP3AFVFrtEnIrYq e9oSnU5f0CH/aVZksMrT3KtaAIJ5KIrJ6nbLzss8TWgHsg2oXEMwxHRHzYlg8Y8OiUPzXu oP1c7mFpC1TjTdg/sCQWFQ/CCUDUhDI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663671744; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RyzpQ/zAY/P8qCbK+LN6dCAVlOM6RNQSvrpJE5uT9W0=; b=S8QHI65LgwCdTCUFmELsIiYo4UF6twBe5wFwFTLayiTSdY6ylZiolY0LNI5GsF6Zgo5776 SSHAA+tPo0CuZe89aOF88Wv9FM2t4ALURXiNsfPP4MVwkxu/aCJQ40MGErgTZ/xXO2jJS9 JUey/Z+Y5SU4TXw0QZDFqVuq8TtZELw= X-Stat-Signature: djotbyxbewhoj9f5ykrhn3gjksbujzen X-Rspamd-Queue-Id: 17ED0120011 Authentication-Results: imf29.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf29.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.136.52 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1663671743-608670 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 Tue, Sep 20, 2022 at 05:38:30PM +0800, Zhenhua Huang wrote: > > > > Also this patch doesn't really explain why it should work and honestly > > > > it doesn't really make much sense to me either. > > > Sorry, my fault. IMO, The reason it should work is, say for this case of > > > order 3 allocation: we can perform direct reclaim more times as we have only > > > order 2 pages(which *lowered* by this change) in free_list(8214*16kB (UEC)). > > > The order requirement which I have lowered is should_reclaim_retry -> > > > __zone_watermark_ok: > > > for (o = order; o < MAX_ORDER; o++) { > > > struct free_area *area = &z->free_area[o]; > > > ... > > > for (mt = 0; mt < MIGRATE_PCPTYPES; mt++) { > > > if (!free_area_empty(area, mt)) > > > return true; > > > } > > > > > > Order 2 pages can be more easily met, hence VM has more chance to return > > > true from should_reclaim_retry. > > > > This is a wrong approach to the problem because there is no real > > guarantee the reclaim round will do anything useful. You should be > > really looking at the compaction side of the thing. > > Thanks Michal for the advice, I'll look at from compaction side also. But I > have one further question, IMO reclaim(~2GB LRU pages can be reclaimed) > should be more feasible compared to compaction(already tried with highest > prio and failed) in this case? Could you please elaborate more...it seems I > still not fully understand why it's a wrong approach to check from reclaim > phase. > Because it risks major slowdowns due to excessive reclaim. Early support used "lumpy reclaim" instead of compaction and resulted in major stalls when trying to allocate THP resulting in THP often being disabled. The success rates were great but systems could become unusable for several minutes and ultimately this resulted in compaction and the current backoff logic of reclaim. Your scenario is similar, you want to aggressively trying to shrink slabs in case an order-3 block of pages gets freed. It might succeed but the system grinds to a halt with excessive re-reading of information from the disk for other use cases. Your focus likely should be on reclaim and compaction aborting prematurely because free CMA pages are available at the correct order but the calling context cannot use CMA pages. It's strange to hear of a driver that has a strict need for order-3 pages being available at all times due to a lack of an IOMMU because that is going to be fragile. One point of CMA was to carve out a region for such drivers so they could the contiguous regions they needed. I believe phone cameras were an early example. If your driver has strict requirements for high-order page availability then CMA probably should be configured and the driver should use CMA. -- Mel Gorman SUSE Labs