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.6 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 A7DF6C4338F for ; Tue, 24 Aug 2021 09:33:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0260D61374 for ; Tue, 24 Aug 2021 09:33:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0260D61374 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 710466B006C; Tue, 24 Aug 2021 05:33:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6BFD36B0071; Tue, 24 Aug 2021 05:33:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 588EE8D0001; Tue, 24 Aug 2021 05:33:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0037.hostedemail.com [216.40.44.37]) by kanga.kvack.org (Postfix) with ESMTP id 3C1256B006C for ; Tue, 24 Aug 2021 05:33:16 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id D2BF31802851F for ; Tue, 24 Aug 2021 09:33:15 +0000 (UTC) X-FDA: 78509460750.25.41B02AE Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf26.hostedemail.com (Postfix) with ESMTP id 3EDF620019EE for ; Tue, 24 Aug 2021 09:33:15 +0000 (UTC) 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-out2.suse.de (Postfix) with ESMTPS id BC14C2004F; Tue, 24 Aug 2021 09:33:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1629797593; 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=aa2IFCsLxfqRjxsUUy9himHqV5OEDziRgIISG1LseDo=; b=w6KaASVqywvloehtOW2QzDabGDFwlTpekXKC4/fdFJL6fBeU6mUGsJLvXRvfA0OcaN42Cs ib9KDlAS7rvFxs5+MW9JDIGNeLtEJzLe6aqQ9oqfzFvcR3LLxY7zAol5nDokgCmnru6iiA FWf0++A+2LM5xh1JmXqQ0OAdrpyRWsY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1629797593; 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=aa2IFCsLxfqRjxsUUy9himHqV5OEDziRgIISG1LseDo=; b=g4+UBKySpB0gpToE0DGpWeq6Sp2aUsjz5KuAJ25+OVkEYwlU7UNiXkxSSePeFhoixFSfGJ hKP37HcXiMvBxPDg== 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 92978136DD; Tue, 24 Aug 2021 09:33:13 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id avjJItm8JGFxBQAAGKfGzw (envelope-from ); Tue, 24 Aug 2021 09:33:13 +0000 Message-ID: <1dfa1b2b-9add-38cc-43cd-8b4b071a4d55@suse.cz> Date: Tue, 24 Aug 2021 11:33:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.0.1 Content-Language: en-US To: Michal Hocko , Chris Down Cc: Kefeng Wang , linux-mm@kvack.org, Andrew Morton , Muchun Song , Matthew Wilcox , Chunxin Zang References: <20210818152239.25502-1-vbabka@suse.cz> <47437115-1a84-c1d1-d91e-1d23cf7f4a5d@suse.cz> From: Vlastimil Babka Subject: Re: [PATCH] mm, vmscan: guarantee drop_slab_node() termination In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=w6KaASVq; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=g4+UBKyS; spf=pass (imf26.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 3EDF620019EE X-Stat-Signature: u5a8z4qn1ityoeujpkygdzp9zyddmi8r X-HE-Tag: 1629797595-307787 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 8/19/21 16:16, Michal Hocko wrote: > On Thu 19-08-21 14:21:08, Chris Down wrote: >> >> Yeah, but we already draw the line at 10 right now. `freed > 10 && retries < >> MAX_RECLAIM_RETRIES` seems easier to reason about, at least to me, and stays >> closer to the current behaviour while providing a definitive point of loop >> termination. The doubling threshold is also definitive :) 64 iterations on 64-bit systems, 32 on 32 bit. In practice it will be much less. > I have to say that I am not really a fan of MAX_RECLAIM_RETRIES approach > especially for user interfaces. Any limit on retries has kicked us back > (e.g. offlining for the memory hotplug just to mention one of those). > drop_caches can take a long time on its own even without retrying. We > should teach people to interrupt those operations if they should really > finish early (e.g. timeout $TIMEOUT echo > /proc/sys/vm/drop_caches) > rather than trying to be extra clever here. I'm afraid the retries vs threshold has more potential for bikeshedding than actual difference in practice. I can change it if more people prefer that way. > I am not against the patch Vlastimil is proposing because it replaces an > ad-hoc limit on the reclaimed objects threshold with something that is > less "random" - sort of a backoff instead seems like an improvement to > me. But I would still be worried that this could regress for some users > so in an ideal world the existing bail on signal should be enough. My point of view on this is: - first let's not forget this is an interface intended for debugging, that we generally discourage to use in a regular manner. Yet it exists, so people will inevitably use it from automated scripts and cron and whatnot. - as such there are no guarantees how much it reclaims, it's a best effort really. If a user thinks it hasn't reclaimed enough, they can always implement own userspace loop that checks e.g. meminfo or slabinfo to decide whether to do another iteration of drop_caches. - while the userspace loop might be convoluted, the idea of running with timeout is not obvious. One might see the operation finishes fine in initial testing, put it in cron etc. without timeout, and one day the infinite loop kicks in and there's trouble. So I think the safer default that avoids suprises is to guarantee termination rather than aggressive reclaim.