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=-8.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 3B297C4320E for ; Mon, 30 Aug 2021 10:11:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 21614610A1 for ; Mon, 30 Aug 2021 10:11:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236366AbhH3KMh (ORCPT ); Mon, 30 Aug 2021 06:12:37 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:57548 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229901AbhH3KMX (ORCPT ); Mon, 30 Aug 2021 06:12:23 -0400 Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 18FE122113; Mon, 30 Aug 2021 10:11:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1630318289; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AJ1hz0iq6S45sTbD6okU7tBzH0QgE93nbBtJ8pDyR4U=; b=m+yizlBkxYFIBtEZmki4vWFvhuKLTglJPAZNV4Z5e9y5Rw/kDsPSMhqjCrwgZpzePo81rQ 2lu9BbAIElOjHhf550UkPSNIIdw4vPgmVBzLXTtGdAO7RdxBytgmaERfVE1HL5lXgOcx8q qPP7RtPulx7k3SGiNimxaCTCY+/3XQk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1630318289; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AJ1hz0iq6S45sTbD6okU7tBzH0QgE93nbBtJ8pDyR4U=; b=7V1sCrVl5hoCrIRMc6CwEaBt9wbAwalLV2AGcIiKGzl/s0rgZNYOoMIbCdOt6U6x6yGw7v HspC6Pe9JbRLLgBQ== Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap1.suse-dmz.suse.de (Postfix) with ESMTPS id D303513670; Mon, 30 Aug 2021 10:11:28 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id EIAzMtCuLGHpQQAAGKfGzw (envelope-from ); Mon, 30 Aug 2021 10:11:28 +0000 Message-ID: Date: Mon, 30 Aug 2021 12:11:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.0.2 Content-Language: en-US To: Mike Kravetz , Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, David Hildenbrand , Michal Hocko , Oscar Salvador , Zi Yan , Muchun Song , Naoya Horiguchi , David Rientjes , Hillf Danton References: <20210816224953.157796-1-mike.kravetz@oracle.com> <20210816162749.22b921a61156a091f3e1d14d@linux-foundation.org> <20210816184611.07b97f4c26b83090f5d48fab@linux-foundation.org> <10d86c18-f0cf-395f-4209-17ac71b9fc03@oracle.com> <2d826470-d345-0196-1359-b79ed08dfc66@oracle.com> From: Vlastimil Babka Subject: Re: [PATCH RESEND 0/8] hugetlb: add demote/split page functionality In-Reply-To: <2d826470-d345-0196-1359-b79ed08dfc66@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/28/21 01:04, Mike Kravetz wrote: > On 8/27/21 10:22 AM, Vlastimil Babka wrote: > I 'may' have been over stressing the system with all CPUs doing file > reads to fill the page cache with clean pages. I certainly need to > spend some more debug/analysis time on this. Hm that *could* play a role, as these will allow reclaim to make progress, but also the reclaimed pages might be stolen immediately and compaction will return COMPACT_SKIPPED and in should_compact_retry() we might go through this code path: /* * compaction was skipped because there are not enough order-0 pages * to work with, so we retry only if it looks like reclaim can help. */ if (compaction_needs_reclaim(compact_result)) { ret = compaction_zonelist_suitable(ac, order, alloc_flags); goto out; } where compaction_zonelist_suitable() will return true because it appears reclaim can free pages to allow progress. And there are no max retries applied for this case. With the reclaim and compaction tracepoints it should be possible to confirm this scenario.