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 4660CEE49AC for ; Mon, 21 Aug 2023 07:55:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B1652900002; Mon, 21 Aug 2023 03:55:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC5C78D0001; Mon, 21 Aug 2023 03:55:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 98DBD900002; Mon, 21 Aug 2023 03:55:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8876B8D0001 for ; Mon, 21 Aug 2023 03:55:35 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 49CD7140B4D for ; Mon, 21 Aug 2023 07:55:35 +0000 (UTC) X-FDA: 81147352230.25.C54F297 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf25.hostedemail.com (Postfix) with ESMTP id 4B9F9A0018 for ; Mon, 21 Aug 2023 07:55:33 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=KmVbkxgX; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692604533; 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:dkim-signature; bh=IwtOeMmA50HvxmSbZZZooAwwT+ziPY1jMwwTjLWzzcs=; b=TY2XcD/OjwGzVEeqBPYSWavR3X0OrznnUro4Jei6K+VjCedWUdjNWYuvQLb2MEh6Xn9Y1D UD8bvu5+jmSXUjlbjTRbvT9ECCTvxFGVjUnvH9tgumQZwia8JjqZjKej9C82GQo0lGzMG5 o9T4bpES2Poo8MgqBcrp0Cehjoqpn08= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=KmVbkxgX; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692604533; a=rsa-sha256; cv=none; b=fKsSdIIyJjD37AGVRpq2UFNd7SMFhteltRRVmbcSQl6FBOwfZ3wttfy8bzdsQuu40vNBcE qTmcTxFesDMPFWek0ys9W7Sv7F2pOG8GDvTnk8dMasPLg6H0C0mUcNZpbURRYfOVLW3JIB AmgWU++uddMKltAgfKLcErJG4wG379c= 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-out1.suse.de (Postfix) with ESMTPS id F31A322963; Mon, 21 Aug 2023 07:55:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1692604530; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=IwtOeMmA50HvxmSbZZZooAwwT+ziPY1jMwwTjLWzzcs=; b=KmVbkxgXki4WY+h9XrPGY0W8fviA1OF1lbxINTBcEIaYvMOKqf9ImsMr9QE4pxkJCYnOYB UwYWdjhEWgu23PD9+NlfdykkUhYZR9KAmUo/fxg4jJQSiDTCwwC4iu7lebozoBg+NbYV2k Dk4tB4jv9zy5DxRYlVteunOJHLLjXuk= 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 D514C1330D; Mon, 21 Aug 2023 07:55:29 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id DMEIMXEY42SsKgAAMHmgww (envelope-from ); Mon, 21 Aug 2023 07:55:29 +0000 Date: Mon, 21 Aug 2023 09:55:27 +0200 From: Michal Hocko To: "Huang, Ying" Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christoph Lameter , Mel Gorman , Vlastimil Babka Subject: Re: [PATCH] mm: fix draining remote pageset Message-ID: References: <20230811090819.60845-1-ying.huang@intel.com> <87r0o6bcyw.fsf@yhuang6-desk2.ccr.corp.intel.com> <87jztv79co.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87jztv79co.fsf@yhuang6-desk2.ccr.corp.intel.com> X-Rspamd-Queue-Id: 4B9F9A0018 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 1yczx5mhsqi36ayoqp1398u9ef85nmoi X-HE-Tag: 1692604533-943447 X-HE-Meta: U2FsdGVkX18FEhNqLJgqTyUSyBwrRmc3agqfTC8jW43/7hGblzr2ieb48yhKaDCorKVlps/c8hiLK2SXXVy39c27HQQyBzGflgyu5dsC3UbzzwlHd24rLeDT0TQPvt1oqaQ2EgKNMxbxzQtHR29OwavjSB8SV+YANUJrwFumqcole175SznrXSUmXFfj94kzUKfqPVJdTzbAG0KDvvJkOsEcaG3WjhLOL7pChzd5EVynqK0xFx6BvbpbEPzjaVdIw7jXcg7oroF0lNkqQkfjNl47JjeOxoAXgYBNCarGwQzb4ncFIoVVaDQ57jK+fyJs8/CXmwHRCJyxvpdlUqIgBIVWWKFCYZ9gubBid9Wthq/NWH8b0wGwcnFFBgCvb7O0XQd38TTbCk/fTrNE8ijrugj8OzkoI36xCv82tV/HnhK/D5wm8EjkC2jUfl2wylbpFQZdUKPWkBsEYgGLndXCRwLSbP2F8/TVQUYdqBk5sbT2iiRurrIW56ukE0a6iH23ZOBjRR4OuZO3OQFr5A9LoB1stlFTSaw1202xdb4kORY+OW+1QEkUObbiAByL+y86F2ahHOpim7HYM+cUxgF5kwJ4mkdnkKIeJjlpdt6vAIr2YIzfPfn/2HCDt8NDHtZUTC/CECl7rhPzshU9jTn/KSTPWCpb2lGaNZiM7/mofJEZ7yUHF+Ay193zbamQ0VY1siYCCzfisj8Puyn32Y4ycP1vpRmIIv0yJb+SD2Bo8QHkQbIZ4qkH9QY9KEJi2VTrPZXS2IopNpOsd8aR1UpVUBLdec+VVqDj9rbxan+mfoy32rceZdqIbNpxrH5tsTxlTGknDW7NwZEQ19pFi9GCfHELYk3eBF0Ee2DtUYdpINmzqPL7TpGgPuSA7crX1HNkFQdXYWrmNd1Mq0fU5xa/l+2ceaum4Zw74MoRuwcwZgzKPb803JyCB0JVsoIle5SI+JzYhr62qjyyNuNfPwc wXGO9Nmj Mus/hUAIUqJYT/WCGf3IYpz3uZTMoqddRrQS4nRLS4g0NkhkQBnS9nohiuAcdBRdmWg/FMJLphO1+1XfkPB8upckKWCg8DavOcoiahwu+DYYBoJHjbDT6+UXaoTI2rgQQBf7IwgrhzYDHyWIggGvQacjIYWIF73jAS5Y1BdeE6bkkfhoLYnrSydHC4vxlmjSumrftmzATMV+aTI4= 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 Wed 16-08-23 15:08:23, Huang, Ying wrote: > Michal Hocko writes: > > > On Mon 14-08-23 09:59:51, Huang, Ying wrote: > >> Hi, Michal, > >> > >> Michal Hocko writes: > >> > >> > On Fri 11-08-23 17:08:19, Huang Ying wrote: > >> >> If there is no memory allocation/freeing in the remote pageset after > >> >> some time (3 seconds for now), the remote pageset will be drained to > >> >> avoid memory wastage. > >> >> > >> >> But in the current implementation, vmstat updater worker may not be > >> >> re-queued when we are waiting for the timeout (pcp->expire != 0) if > >> >> there are no vmstat changes, for example, when CPU goes idle. > >> > > >> > Why is that a problem? > >> > >> The pages of the remote zone may be kept in the local per-CPU pageset > >> for long time as long as there's no page allocation/freeing on the > >> logical CPU. In addition to the logical CPU goes idle, this is also > >> possible if the logical CPU is busy in the user space. > > > > But why is this a problem? Is the scale of the problem sufficient to > > trigger out of memory situations or be otherwise harmful? > > This may trigger premature page reclaiming. The pages in the PCP of the > remote zone would have been freed to satisfy the page allocation for the > remote zone to avoid page reclaiming. It's highly possible that the > local CPU just allocate/free from/to the remote zone temporarily. I am slightly confused here but I suspect by zone you mean remote pcp. But more importantly is this a concern seen in real workload? Can you quantify it in some manner? E.g. with this patch we have X more kswapd scanning or even hit direct reclaim much less often. > So, > we should free PCP pages of the remote zone if there is no page > allocation/freeing from/to the remote zone for 3 seconds. Well, I would argue this depends a lot. There are workloads which really like to have CPUs idle and yet they would like to benefit from the allocator fast path after that CPU goes out of idle because idling is their power saving opportunity while workloads want to act quickly after there is something to run. That being said, we really need some numbers (ideally from real world) that proves this is not just a theoretical concern. -- Michal Hocko SUSE Labs