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 44CD8C433EF for ; Sat, 2 Jul 2022 15:24:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5477C6B0071; Sat, 2 Jul 2022 11:24:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D0536B0073; Sat, 2 Jul 2022 11:24:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 398C66B0074; Sat, 2 Jul 2022 11:24:49 -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 266446B0071 for ; Sat, 2 Jul 2022 11:24:49 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id EBC0780E9E for ; Sat, 2 Jul 2022 15:24:48 +0000 (UTC) X-FDA: 79642532256.23.FF4052E Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174]) by imf08.hostedemail.com (Postfix) with ESMTP id 8F66D160042 for ; Sat, 2 Jul 2022 15:24:48 +0000 (UTC) Received: by mail-vk1-f174.google.com with SMTP id a15so2472061vkl.10 for ; Sat, 02 Jul 2022 08:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZYZxdXmI/oglg81rAbUCzetEWnT1Q+bPvxIhgaktwM8=; b=IVSWWCBj8x0AWjUc6w+J7bpVrU44M69imdesfjdBk5WShd97zxgnPZmCUC67U5YEF/ D9GX3ccJxcJvoV76lcYQjRSv174srX1pjqfBNsJgUd+F6U/r4ykPHIzt3bqWMUqqKLud GuXcP1qhwrrhhDhkO3LiDiM9T+7/wfIXbMD35UfCPZKrUarI3Ja4XUfDBhmOE60HnaMq SSoc4CN0O+3+i7LQ1I2D3CxkYu1jyVf7/D/uV1CRsHievNI82KEaoq60oStuiw1p5MGd RUDeNiIkPo6iWIgA1E7C8p8tW13fXN7SvcBD0ODcYaVL+nlh++ImcLcnToulRrwiql/T Srjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZYZxdXmI/oglg81rAbUCzetEWnT1Q+bPvxIhgaktwM8=; b=yWGMtnUmm+3rJwmEAyXsK41zuz5/VcnwvfimslKzQCybE5zTmd3rDlKqdFNVTOiLLN qykPunkQGNF1txS0OGrugpMx0B+h+lMm/TJBZrK9D4V2PpgCjvYJSVK4k9+cUV5tKEWk +gHAqI9yH6bg3AulCl+Y0zy0c3Gdc2ObZjq1Ghmrd+8ZC82w+W2IvZvjzCg/59hhHvYA mQUbLr/BsmVxRdKq2ww2zt2ewtODESqRvc2lS5RV0MQO/YeocLT2tzIpT98Geq3tLHrj n/avnCnikTITeKLv4aCfczdWcwZkfRSNXSFxPVtJQmDdujBFNu0Dr6Kd9JM+l37V4btW TgtA== X-Gm-Message-State: AJIora/A2KSgpBkwfwzMgS3WLE1wMoAx/JkMIcoRJDz3Ow3XDyCCb/Ab +VFsvWBZ2wraGaTm2D4xnMWPBTsiD/ckW1vJj6o= X-Google-Smtp-Source: AGRyM1vP4VSPyWx6KiG+X/l6QGlfPV13N6qDlO3QVXdevWwtM0jnlh+r6nidF/V8xr5OwCPOf/I+KBb3YEab8SpvxSI= X-Received: by 2002:a1f:a348:0:b0:36f:be56:9381 with SMTP id m69-20020a1fa348000000b0036fbe569381mr13893192vke.8.1656775487791; Sat, 02 Jul 2022 08:24:47 -0700 (PDT) MIME-Version: 1.0 References: <20220619155032.32515-1-laoar.shao@gmail.com> In-Reply-To: From: Yafang Shao Date: Sat, 2 Jul 2022 23:24:10 +0800 Message-ID: Subject: Re: [RFC PATCH bpf-next 00/10] bpf, mm: Recharge pages when reuse bpf map To: Roman Gushchin 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 Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656775488; a=rsa-sha256; cv=none; b=LbQAl3yV5U3wrs+LPIRAhoKF5icCGMe5VUt7n9qf6k4EWLeqFGL4eIx8EIpXW8DAIo4IO1 /OIVk0RPGfBnZmQCdfy+3xV5dyiJJkFC/O5ZQIjMTsY6HKbQWSFYijKd3u+R7onYB+5e4k 2Z+70uV/PbyRpP8e9Jpgo9XtFW+otC0= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=IVSWWCBj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.221.174 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656775488; 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=ZYZxdXmI/oglg81rAbUCzetEWnT1Q+bPvxIhgaktwM8=; b=k+dwBBPFWNGM07PEZxRTB+tEMHU2P0Faea+XxFtOgN3vJuTpBb5LTnOqTRbwue4B5KR1su MIKCYnnU9h6+Wk4aWFzjjJSFR/YlsFIcVBAnfzWNURazJw5qaSnuB/vhOlOIt8CSeoTNu0 IrFEuUyYdsKIgE4/vri5/2lFWyPZMfE= Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=IVSWWCBj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.221.174 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 8F66D160042 X-Stat-Signature: 6cucbz16h1idynfyxpcsoarudf73o3dn X-Rspam-User: X-HE-Tag: 1656775488-331555 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 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. -- Regards Yafang