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 AF143C43334 for ; Sat, 2 Jul 2022 15:34:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2DA536B0071; Sat, 2 Jul 2022 11:34:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 23C9A6B0073; Sat, 2 Jul 2022 11:34:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 104106B0074; Sat, 2 Jul 2022 11:34:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id EE6A36B0071 for ; Sat, 2 Jul 2022 11:34:01 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id B2F3E120DF1 for ; Sat, 2 Jul 2022 15:34:01 +0000 (UTC) X-FDA: 79642555482.31.7DC3563 Received: from out2.migadu.com (out2.migadu.com [188.165.223.204]) by imf16.hostedemail.com (Postfix) with ESMTP id 2D82618006A for ; Sat, 2 Jul 2022 15:34:01 +0000 (UTC) Date: Sat, 2 Jul 2022 08:33:50 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1656776038; h=from:from:reply-to:subject:subject: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=0koBQrdHPcVIUR0L54i8lw1aAxWvfXxTIhqNWGsnhmE=; b=VSNnpIb3zPiCa58T1nsR3vom50wd/wka/ztKLz371Ix5/hMY3NzqK93ODr55G0qEPqNPl4 buHd+gw0qSE2Wgi2F+hfHU4spW53a4Ympe3sHqXYQPUkHYgu6wdz01MQdnW1AbD/C1pf0l ZnPtikl8Xw5OoTdftSJIcNg8ScLpwvc= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Yafang Shao Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin Lau , Song Liu , Yonghong Song , john fastabend , KP Singh , Quentin Monnet , Johannes Weiner , Michal Hocko , Shakeel Butt , Muchun Song , Andrew Morton , Christoph Lameter , penberg@kernel.org, David Rientjes , iamjoonsoo.kim@lge.com, Vlastimil Babka , Linux MM , bpf Subject: Re: [RFC PATCH bpf-next 00/10] bpf, mm: Recharge pages when reuse bpf map Message-ID: References: <20220619155032.32515-1-laoar.shao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=VSNnpIb3; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf16.hostedemail.com: domain of roman.gushchin@linux.dev designates 188.165.223.204 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656776041; a=rsa-sha256; cv=none; b=W8Vj9xbLLAl9sX3SHRm3XF7FmaJbxgtmlH1D/EZuy0vNEo6cVDoichj8tEjIuAehag4B52 mfLT9+1SaLZXQ8rH9CgGitsDJnkxE4H5UCNJoa3ap+ZnFlHerDbJ86gKgUd+Aoyw/55zNa ZKqFEyD9zneyLS3vCYJd7KRT+o+ID5A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656776041; 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=0koBQrdHPcVIUR0L54i8lw1aAxWvfXxTIhqNWGsnhmE=; b=cS4orddQ2NS0VLEQlqa+HxgdCqhzeNqsnVCIG0Uup/4LU248vAdnv+oFt7j5vA1tK9tnHU DBtr2K6v9rsEn3F2sL4EhzPtKMj0eaSE2KNpQMne28JRHeETBI1NkpWRZV70U6mdtDDaXv HEmd34lR2cZJVt5bZuxtBtUIZN3O7aA= X-Stat-Signature: o5fiah1snnisud89kntbucebhajqickk X-Rspamd-Queue-Id: 2D82618006A Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=VSNnpIb3; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf16.hostedemail.com: domain of roman.gushchin@linux.dev designates 188.165.223.204 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1656776041-553588 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 Sat, Jul 02, 2022 at 11:24:10PM +0800, Yafang Shao wrote: > On Sat, Jul 2, 2022 at 12:23 PM Roman Gushchin wrote: > > > > On Sun, Jun 26, 2022 at 02:25:51PM +0800, Yafang Shao wrote: > > > > > htab->map.numa_node); > > > > > And then we'd better introduce an improvement for memcg, > > > > > + /* > > > > > + * Should wakeup async memcg reclaim first, > > > > > + * in case there will be no direct memcg reclaim for a long time. > > > > > + * We can either introduce async memcg reclaim > > > > > + * or modify kswapd to reclaim a specific memcg > > > > > + */ > > > > > + if (gfp_mask & __GFP_KSWAPD_RECLAIM) > > > > > + wake_up_async_memcg_reclaim(); > > > > > if (!gfpflags_allow_blocking(gfp_mask)) > > > > > goto nomem; > > > > > > > > Hm, I see. It might be an issue if there is no global memory pressure, right? > > > > Let me think what I can do here too. > > > > > > > > > > Right. It is not a good idea to expect a global memory reclaimer to do it. > > > Thanks for following up with it again. > > > > After thinking a bit more, I'm not sure if it's actually a good idea: > > there might be not much memory to reclaim except the memory consumed by the bpf > > map itself, so waking kswapd might be useless (and just consume cpu and drain > > batteries). > > > > I'm not sure if it is a generic problem. > For example, a latency-sensitive process running in a container > doesn't set __GFP_DIRECT_RECLAIM, but there're page cache pages in > this container. If there's no global memory pressure or no other kinds > of memory allocation in this container, these page cache pages will > not be reclaimed for a long time. > Maybe we should also check the number of page cache pages in this > container before waking up kswapd, but I'm not quite sure of it. It's not a generic problem but it might be very specific. Anyway, it doesn't really matter, we shouldn't exceed memory.max.