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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96114C47081 for ; Mon, 4 Apr 2022 21:23:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379994AbiDDVVQ (ORCPT ); Mon, 4 Apr 2022 17:21:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35256 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1379517AbiDDRVQ (ORCPT ); Mon, 4 Apr 2022 13:21:16 -0400 Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D72B6E098 for ; Mon, 4 Apr 2022 10:19:19 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id y6so8713492plg.2 for ; Mon, 04 Apr 2022 10:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uhZvWBIYSPxrHtL/UXP4sOCKqMqAgTQ5cHbzprIzUlI=; b=rzW4aaUe8wJHBTW/ExLvJddgYRg1t4YhtSpQVQScLfUwXMUjqtSxLLNi52Rpn5/B9e 4fm33kwEjNNC8PObxWVWNVFke/MshRfAUZolEP0oeRGIcWs1cMZ8dqnCMHUOTSSXF2R+ Nxc7bj+ITBZAcBUCg6yEKcw6zz2obIN/RDEpBS+4YLPJ4AjvRWmQYm9ga69a1RiY4EDX oGzty137ABa8Ztyvwr1RlrkdXRpVcepr1eO0rJxfGr76K3XVs6VQ3L6PIza3Wro/7erv oZSbbPlhDhdZagCPj0TuB4euNN0h0a1bfMWvh80WoOYfDkjShCEByhv1m6HFJ/OrDhaM E/NQ== 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=uhZvWBIYSPxrHtL/UXP4sOCKqMqAgTQ5cHbzprIzUlI=; b=pM66YnWM8SHnkgDiqATaY1RBFeNN2dFvjerTM2zOmrj2Rq5MkMu7IhigSXLm4ntf2A GBvmUJCG0kTTMevSZ9mcRhY5VhnN9dKMYU/le2QisR0ZsrdYCXVrp/WA8PEX5lfttq9S wQrPQK0SJJS3VTcN/Y8TJ/SnWL8p8j39qYjKMfYph/qZXtW13nQc5HztlAh6vRhiR0ZC KNpG9KAdTDUBAMZBTOJ7rP/B9V/bzycf42IjucncNu0MK8ZVENoeLG4QSR/p0+Y4KWVp K3MADm967jX8ozeJdk4UHJnrX0b/9N3LRnBAj0/iJSbtGXZ0nT/yF2u5fTZRtJJ8tMMO 4hWA== X-Gm-Message-State: AOAM532+9NfYQnfN3HStcPM7gM5/JCjhdxN/3YFJpD53WhHwFrinBkUn i4cZYDYyWXPyXtQLKUI3hwc0XV9sA0w4WcRG8doBcA== X-Google-Smtp-Source: ABdhPJz50EolXnmloOFRdflV7luhmQEbXQ6TLx1sRiAzjczB5dC9hpz0y8SCGJwdMY8U2thvWleWIxvnBRXFYbPjKbA= X-Received: by 2002:a17:903:2351:b0:156:a562:b3f8 with SMTP id c17-20020a170903235100b00156a562b3f8mr670651plh.81.1649092759112; Mon, 04 Apr 2022 10:19:19 -0700 (PDT) MIME-Version: 1.0 References: <20220331084151.2600229-1-yosryahmed@google.com> <874k3d6vuq.fsf@vajain21.in.ibm.com> <871qyd7bif.fsf@vajain21.in.ibm.com> In-Reply-To: <871qyd7bif.fsf@vajain21.in.ibm.com> From: Yosry Ahmed Date: Mon, 4 Apr 2022 10:18:42 -0700 Message-ID: Subject: Re: [PATCH resend] memcg: introduce per-memcg reclaim interface To: Vaibhav Jain Cc: Johannes Weiner , Michal Hocko , Shakeel Butt , Andrew Morton , David Rientjes , Tejun Heo , Zefan Li , Roman Gushchin , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, Linux Kernel Mailing List , Linux-MM , Jonathan Corbet , Yu Zhao , Dave Hansen , Wei Xu , Greg Thelen Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Apr 3, 2022 at 8:50 PM Vaibhav Jain wrote: > > > Apologies for the delayed response, > > Yosry Ahmed writes: > > > On Fri, Apr 1, 2022 at 1:39 AM Vaibhav Jain wrote: > >> > >> > >> Yosry Ahmed writes: > >> > From: Shakeel Butt > >> > > >> > Introduce an memcg interface to trigger memory reclaim on a memory cgroup. > >> > >> > >> > + > >> > + while (nr_reclaimed < nr_to_reclaim) { > >> > + unsigned long reclaimed; > >> > + > >> > + if (signal_pending(current)) > >> > + break; > >> > + > >> > + reclaimed = try_to_free_mem_cgroup_pages(memcg, > >> > + nr_to_reclaim - nr_reclaimed, > >> > + GFP_KERNEL, true); > >> > + > >> > + if (!reclaimed && !nr_retries--) > >> > + break; > >> > + > >> > + nr_reclaimed += reclaimed; > >> > >> I think there should be a cond_resched() in this loop before > >> try_to_free_mem_cgroup_pages() to have better chances of reclaim > >> succeding early. > >> > > Thanks for taking the time to look at this! > > > > I believe this loop is modeled after the loop in memory_high_write() > > for the memory.high interface. Is there a reason why it should be > > needed here but not there? > > > > memory_high_write() calls drain_all_stock() atleast once before calling > try_to_free_mem_cgroup_pages(). This would drain all percpu stocks > for the given memcg and its descendents, giving a high chance > try_to_free_mem_cgroup_pages() to succeed quickly. Such a functionality > is missing from this patch. > > Adding a cond_resched() would atleast give chance to other processess > within the memcg to run and make forward progress thereby making more > pages available for reclaim. > > Suggestion is partly based on __perform_reclaim() issues a cond_resche() > as it may get called repeatedly during direct reclaim path. > As Michal pointed out, there is already a call to cond_resched() in shrink_node_memcgs(). > > >> > >> > >> -- > >> Cheers > >> ~ Vaibhav > > > > -- > Cheers > ~ Vaibhav