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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E7DBC54FB9 for ; Thu, 16 Nov 2023 09:59:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230304AbjKPJ7L (ORCPT ); Thu, 16 Nov 2023 04:59:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229749AbjKPJ7J (ORCPT ); Thu, 16 Nov 2023 04:59:09 -0500 Received: from outbound-smtp16.blacknight.com (outbound-smtp16.blacknight.com [46.22.139.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B05EC5 for ; Thu, 16 Nov 2023 01:59:04 -0800 (PST) Received: from mail.blacknight.com (pemlinmail05.blacknight.ie [81.17.254.26]) by outbound-smtp16.blacknight.com (Postfix) with ESMTPS id C087B1C405A for ; Thu, 16 Nov 2023 09:59:02 +0000 (GMT) Received: (qmail 17829 invoked from network); 16 Nov 2023 09:59:02 -0000 Received: from unknown (HELO mail.blacknight.com) (mgorman@techsingularity.net@[81.17.254.19]) by 81.17.254.26 with ESMTPA; 16 Nov 2023 09:59:02 -0000 Date: Thu, 16 Nov 2023 09:59:01 +0000 From: Mel Gorman To: Charan Teja Kalla Cc: akpm@linux-foundation.org, mhocko@suse.com, david@redhat.com, vbabka@suse.cz, hannes@cmpxchg.org, quic_pkondeti@quicinc.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V2 2/3] mm: page_alloc: correct high atomic reserve calculations Message-ID: <20231116095901.72oqtjoiqzt3tfhj@techsingularity.net> References: <905d99651423ee85aeb7a71982b95ee9bb05ee99.1699104759.git.quic_charante@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <905d99651423ee85aeb7a71982b95ee9bb05ee99.1699104759.git.quic_charante@quicinc.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Nov 05, 2023 at 06:20:49PM +0530, Charan Teja Kalla wrote: > reserve_highatomic_pageblock() aims to reserve the 1% of the managed > pages of a zone, which is used for the high order atomic allocations. > > It uses the below calculation to reserve: > static void reserve_highatomic_pageblock(struct page *page, ....) { > > ....... > max_managed = (zone_managed_pages(zone) / 100) + pageblock_nr_pages; > > if (zone->nr_reserved_highatomic >= max_managed) > goto out; > > zone->nr_reserved_highatomic += pageblock_nr_pages; > set_pageblock_migratetype(page, MIGRATE_HIGHATOMIC); > move_freepages_block(zone, page, MIGRATE_HIGHATOMIC, NULL); > > out: > .... > } > > Since we are always appending the 1% of zone managed pages count to > pageblock_nr_pages, the minimum it is turning into 2 pageblocks as the > nr_reserved_highatomic is incremented/decremented in pageblock sizes. > > Encountered a system(actually a VM running on the Linux kernel) with the > below zone configuration: > Normal free:7728kB boost:0kB min:804kB low:1004kB high:1204kB > reserved_highatomic:8192KB managed:49224kB > > The existing calculations making it to reserve the 8MB(with pageblock > size of 4MB) i.e. 16% of the zone managed memory. Reserving such high > amount of memory can easily exert memory pressure in the system thus may > lead into unnecessary reclaims till unreserving of high atomic reserves. > > Since high atomic reserves are managed in pageblock size granules, as > MIGRATE_HIGHATOMIC is set for such pageblock, fix the calculations for > high atomic reserves as, minimum is pageblock size , maximum is > approximately 1% of the zone managed pages. > > Signed-off-by: Charan Teja Kalla This patch in isolation seems fine with the caveat that such a small system may find the atomic reserves to be borderline useless. Acked-by: Mel Gorman -- Mel Gorman SUSE Labs