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 DF787E95A96 for ; Mon, 9 Oct 2023 07:34:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 444956B01AA; Mon, 9 Oct 2023 03:34:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F47B6B01AB; Mon, 9 Oct 2023 03:34:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BB486B01AE; Mon, 9 Oct 2023 03:34:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 1D17F6B01AA for ; Mon, 9 Oct 2023 03:34:36 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id DE86D1CA2CF for ; Mon, 9 Oct 2023 07:34:35 +0000 (UTC) X-FDA: 81325110510.11.0E08CAF Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf24.hostedemail.com (Postfix) with ESMTP id B983218001E for ; Mon, 9 Oct 2023 07:34:33 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Lfy+gS69; spf=pass (imf24.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696836874; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Ux/+/9XoY3oQURe42Bewxjm9Kmqy/ecxPscylyqtj2E=; b=st1ryg2J43qsW8/Apk2qzL9uP41UTEYGHHhGOwbleupTLBDY4xTUFRZ+2rcoQ5BrHVABzK TACFBif1+Vm4LDvLWWuFZcmEeeSbAoehlsGkGsUEFbWW7h/VtPEuKYN9nfMviesvTHAzwr 127TKAoznD16kirViLtwhPyKGTgWMwQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696836874; a=rsa-sha256; cv=none; b=DEjO9E2q8/I++Qeh4v3hpWFpZMvpiEtKAt9aJfSwzaaUky5Exzy7pXwtvIr5tWWtl+7QD0 twwzTqOtgS1xpCTzrioiq3RU8J89/7tc2TOTNO29SyswpPYT3UQLNS6CVd6Aigy+WW6evd k0BI5iJs+LRfGVvK49BV6z6urlinkZU= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Lfy+gS69; spf=pass (imf24.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (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 BE8B11F38C; Mon, 9 Oct 2023 07:34:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1696836871; 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=Ux/+/9XoY3oQURe42Bewxjm9Kmqy/ecxPscylyqtj2E=; b=Lfy+gS69AXpu3lfZDmrd8R4lwf5xDlm42obXuhcVINuRKO67ywl5EBohdpjiPdRdEyNGBV VLk/c+WHLxkMiBbEjgX96kDpRE0KRKm++tCZ7O+nlJMJ7FdicVtzFqRUkPELaayWTdU21Q IrhmIEa1KPPrqr7SSD/VXYdfxyOqIGs= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (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 imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 9308813905; Mon, 9 Oct 2023 07:34:31 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id ZjJLIwetI2W9JAAAMHmgww (envelope-from ); Mon, 09 Oct 2023 07:34:31 +0000 Date: Mon, 9 Oct 2023 09:34:30 +0200 From: Michal Hocko To: "Huang, Ying" Cc: Jianlin Lv , tj@kernel.org, lizefan.x@bytedance.com, hannes@cmpxchg.org, corbet@lwn.net, roman.gushchin@linux.dev, shakeelb@google.com, muchun.song@linux.dev, akpm@linux-foundation.org, yosryahmed@google.com, willy@infradead.org, linmiaohe@huawei.com, wangkefeng.wang@huawei.com, laoar.shao@gmail.com, yuzhao@google.com, wuyun.abel@bytedance.com, david@redhat.com, peterx@redhat.com, vishal.moola@gmail.com, hughd@google.com, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, jianlv@ebay.com Subject: Re: [PATCH] memcg: add interface to force disable swap Message-ID: References: <20231007130905.78554-1-jianlv@ebay.com> <87mswtkj8x.fsf@yhuang6-desk2.ccr.corp.intel.com> <87il7hjzdp.fsf@yhuang6-desk2.ccr.corp.intel.com> <87edi4jq19.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87edi4jq19.fsf@yhuang6-desk2.ccr.corp.intel.com> X-Rspamd-Queue-Id: B983218001E X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: x87u3d1mpgz9w3a4az9diag1sgimgx1p X-HE-Tag: 1696836873-618678 X-HE-Meta: U2FsdGVkX1/R+5UL0fbOfW/OAIH15iEMpQoAJMY55y12bxnk60Btw4PhLcFGAgVrnZFsBY+5BLFuHEp+mF4KDFd/LcGxkkM6nm80gRmi15pZzV/z1boLGwsFQwM6lETOSwVsfdoYDSw2qyIP40ExM74WmbT7XKY7t0+2zkT0zrgUFHEMUrt6zwCvppNn4++TKSMnFIzoZbQp/1QeRnj9eFyc++U0R8M89EGOM+ZQDriFCCWk1xXJ1KgqNPxQqQPt+mvNZNKdPHiRE/EeVZAesgWbzAVsnIUj7GSFbebeGD7fhQCiVAaUYz8+93rVOj8n72PJnJByys5n0i+9byL5FZ7tQ/C57EVozlnzark1z97wEuaaFSN3NmLyY5tOl7Pzfs39dNHmYlc2g92an7oiGBymn5iD4FOJF599ABDrFK/nGu3YpCSkgidI4CsGVb07k1jjEwo7OWM0Yd2E4uwIVXC588a44zUgCWqnkJkAtZD9/ybnubxFKlxkI5UULH8gTKUBtTJr1KtzAnV8qGJjsqZkKMFOorLeAvDZ3S6SWSokRZGCQbwqSSuTcaz6MC4s+intRIYXcngbLth3nsslsOAeAv6AJuuqI0q2JDTE0R4EbqZaAXc1i4le1Rocg1vavJHeup7pNfe0OmOTZjSct65dTkq6dKpoFycVwCV99wT4bsjO4PVekcbF242rMxT4gBGJ6UhmpcgpqBE+rPx6FQpQPzJNiO9nqmtZD+MoGlEiKc1w87rnsU+8advnGxzGYYAia5Kyssz84C+Rt7xK62qqGicHqgyWeCjg8tH+ibTs2RQqG4iTOsmlhSx7pPeuePwqEwW+x3xJ5/DjYfv3HioXhU2KAnefSbT72E4tGbsIBgmeqIGGYhCD5uIGyY6G4omgkzFq1deqvvz9dkRUnFJuLcPtqFYz/lnZL0iFRORT7xju1Y44pak+nJDIZeOfvS7uKCCriKO/UmrJqqb cqNccTUl oZBomtm9XOXXYIX3+pgPb9kdgG/A7HTGyk/uPC91cIyedZaC7Mb8bV7U5oQozStPsEMh2YMxhE0GgHTazmdE0nrvCF/vwqrBKi37S6VvnYS1aZ7wgnzuXKx9j0//B3s3lsj98qZ09x3zP4xaO8IDycmrIjvwJjTDwtXXnTaH2GMM03sRvf/u/8oskoG6zMyTgXnv7Mt/tBJTObzl9fCENNcEXFzvXUUdZ8at5o4wA+tpeeJx2je1r32NR0QwqPkF43pYkhClBJjx3lvgTHA+Bje+ILxJL0mrP7v3q9hBtP9O0+k5DQqZdKDP9AY2vJ8cHsyWHRvI9sdTVu7E0bhfpz/rxMP3DxvHbQ3H8 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 Mon 09-10-23 13:58:10, Huang, Ying wrote: > Jianlin Lv writes: > > > On Sun, Oct 8, 2023 at 4:26 PM Huang, Ying wrote: > >> > >> Jianlin Lv writes: > >> > >> > On Sun, Oct 8, 2023 at 9:17 AM Huang, Ying wrote: > >> >> > >> >> Jianlin Lv writes: > >> >> > >> >> > From: Jianlin Lv > >> >> > > >> >> > Global reclaim will swap even if swappiness is set to 0. > >> >> > >> >> Why? Can you elaborate the situation? > >> > > >> > We reproduced the issue of pages being swapped out even when swappiness is > >> > set to 0 in the production environment through the following test program. > >> > Not sure whether this program can reproduce the issue in any environment. > >> > > >> > From the implementation of the get_scan_count code, it can be seen that, > >> > based on the current runtime situation, memory reclamation will choose a > >> > scanning method (SCAN_ANON/SCAN_FILE/SCAN_FRACT) to determine how > >> > aggressively the anon and file LRU are scanned. However, this introduces > >> > uncertainty. > >> > > >> > For the JVM issue at hand, we expect deterministic SCAN_FILE scan to avoid > >> > swapping out anon pages. > >> > >> Why doesn't memory.swap.max work? > > > > The main reason is that deployed nodes are kept on cgroups v1. Please note that cgroups v1 is in the maintenance mode with no new functionality to be added. What is the reason you are sticking with v1? > Check the code again. IIUC, for swappiness == 0, anonymous pages will > only be reclaimed if sc->file_is_tiny is true. For the memcg reclaim (i.e. not the global one) we try to avoid swapping even when file_is_tiny IIRC. > If we don't swap in that > situation, OOM may be triggerred. I don't think that it's a good idea > to do that. Or I miss something? Or even worse the system might start trashing heavily over that remaining tiny page cache. -- Michal Hocko SUSE Labs