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 10698C433FE for ; Fri, 25 Feb 2022 01:31:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8168E8D0003; Thu, 24 Feb 2022 20:31:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C5EE8D0001; Thu, 24 Feb 2022 20:31:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68CC88D0003; Thu, 24 Feb 2022 20:31:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 5A9558D0001 for ; Thu, 24 Feb 2022 20:31:37 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2CA0530 for ; Fri, 25 Feb 2022 01:31:37 +0000 (UTC) X-FDA: 79179575034.15.5A5BB5A Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) by imf17.hostedemail.com (Postfix) with ESMTP id 9B9FB40003 for ; Fri, 25 Feb 2022 01:31:36 +0000 (UTC) Received: by mail-yb1-f171.google.com with SMTP id u12so2957021ybd.7 for ; Thu, 24 Feb 2022 17:31:36 -0800 (PST) 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=Pm5OlqNMoBPPLPWK+AwvvZMbTJ1tBSbLkY52q0F+S3s=; b=bOlI1N1e1eCyEuqehuh15D0Gvy9b/v1c8b2gf0lYKV1iM3k3Z6JoSe5FjlGKfWXb/2 NaCdwCt+jOSQaqL4vQSLgfDew5hHTISv6Tw1YYrcs201HsFkh3NcGILcOWQ5G3g+M9Fa rjECSe7kLLlqQnimD4Jx5oHgrY/Vsh33TXLtusWOHgyV5JJrNcT4r9MRrIXsID5+lN0U YgIFJQZ/WFLmL0mQqkhgKLqBh5l4blEc4KugH/+7+LUqYIlYx19+9z5P/Wib4EM2iMwR MYdLKq9/cXjFQNqeC0p0PLk5ttHyex3Ztf60cKD+JFiOqDtFITK+XZ9E6Uo0mRykHKBn i1cQ== 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=Pm5OlqNMoBPPLPWK+AwvvZMbTJ1tBSbLkY52q0F+S3s=; b=xGk0jEyLDc7+tFTGgFnCT+0L0y3YwBNqlx0Lf/OcxFbvS8tHWrUDWfXytKqhmgE2Lk POpe5AJrX6OjCO3EeoDg4m/l/v47jK0IY8Uk4AoW9NIgOJQ2hTlWgq3nlLY/LD7Ybf1n ffB7EL68wF1YZoZ7bZfP8rj7m6Ubc01XUA7I3Y5ZNJc4SqB1EeA4M82UIiHg+jJ7GN++ 88aY402QXfYnZaL0uTvqXaMuv7ium+D2zC6qtsy6jRSAWIgseBHRpjmvUzAI97fh2Y90 Cxn7gemT8rjFLARfn67Ee3bPlEL+rPS7Y++onoxYDa/jofis9t3qXm2xOEvLxt8cMmek 71WA== X-Gm-Message-State: AOAM530bJNKwiPhVuWeY52oQyDDTZ2kskcOFaC7xjOJQ9vmyXGpmpRjC rsZPMNr/BaD/qRPfCaThopppX8Ft/4EQAjTJTPP/1O9lewh96wuZ X-Google-Smtp-Source: ABdhPJxq5UTgxzncAC66DrJulLZMUIXudiXu4IBLN9DiTh43HDSCyrVMnOnXtB5URROdeuNlxLRInLknigMHXy1fXdU= X-Received: by 2002:a25:2693:0:b0:624:50a8:fee9 with SMTP id m141-20020a252693000000b0062450a8fee9mr4975330ybm.348.1645752695454; Thu, 24 Feb 2022 17:31:35 -0800 (PST) MIME-Version: 1.0 References: <20220223194812.1299646-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 24 Feb 2022 17:31:24 -0800 Message-ID: Subject: Re: [PATCH v3 1/1] mm: count time in drain_all_pages during direct reclaim as memory pressure To: Michal Hocko Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, pmladek@suse.com, peterz@infradead.org, guro@fb.com, shakeelb@google.com, minchan@kernel.org, timmurray@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=bOlI1N1e; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf17.hostedemail.com: domain of surenb@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=surenb@google.com X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 9B9FB40003 X-Stat-Signature: 9q4epzfs81ubxxajccccyfyjpi7xapim X-HE-Tag: 1645752696-738664 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 Thu, Feb 24, 2022 at 8:28 AM Suren Baghdasaryan wrote: > > On Thu, Feb 24, 2022 at 12:53 AM 'Michal Hocko' via kernel-team > wrote: > > > > On Wed 23-02-22 11:48:12, Suren Baghdasaryan wrote: > > > When page allocation in direct reclaim path fails, the system will > > > make one attempt to shrink per-cpu page lists and free pages from > > > high alloc reserves. Draining per-cpu pages into buddy allocator can > > > be a very slow operation because it's done using workqueues and the > > > task in direct reclaim waits for all of them to finish before > > > proceeding. Currently this time is not accounted as psi memory stall. > > > > > > While testing mobile devices under extreme memory pressure, when > > > allocations are failing during direct reclaim, we notices that psi > > > events which would be expected in such conditions were not triggered. > > > After profiling these cases it was determined that the reason for > > > missing psi events was that a big chunk of time spent in direct > > > reclaim is not accounted as memory stall, therefore psi would not > > > reach the levels at which an event is generated. Further investigation > > > revealed that the bulk of that unaccounted time was spent inside > > > drain_all_pages call. > > > > > > A typical captured case when drain_all_pages path gets activated: > > > > > > __alloc_pages_slowpath took 44.644.613ns > > > __perform_reclaim took 751.668ns (1.7%) > > > drain_all_pages took 43.887.167ns (98.3%) > > > > Although the draining is done in the slow path these numbers suggest > > that we should really reconsider the use of WQ both for draining and > > other purposes (like vmstats). > > Yep, I'm testing the kthread_create_worker_on_cpu approach suggested > by Petr. Will post it later today if nothing regresses. An RFC for kthreads approach is posted at https://lore.kernel.org/all/20220225012819.1807147-1-surenb@google.com/ > > > > > > PSI in this case records the time spent in __perform_reclaim but > > > ignores drain_all_pages, IOW it misses 98.3% of the time spent in > > > __alloc_pages_slowpath. > > > > > > Annotate __alloc_pages_direct_reclaim in its entirety so that delays > > > from handling page allocation failure in the direct reclaim path are > > > accounted as memory stall. > > > > > > Reported-by: Tim Murray > > > Signed-off-by: Suren Baghdasaryan > > > Acked-by: Johannes Weiner > > > > Acked-by: Michal Hocko > > > > Thanks! > > > > > --- > > > changes in v3: > > > - Moved psi_memstall_leave after the "out" label > > > > > > mm/page_alloc.c | 10 ++++++---- > > > 1 file changed, 6 insertions(+), 4 deletions(-) > > > > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > > index 3589febc6d31..029bceb79861 100644 > > > --- a/mm/page_alloc.c > > > +++ b/mm/page_alloc.c > > > @@ -4595,13 +4595,12 @@ __perform_reclaim(gfp_t gfp_mask, unsigned int order, > > > const struct alloc_context *ac) > > > { > > > unsigned int noreclaim_flag; > > > - unsigned long pflags, progress; > > > + unsigned long progress; > > > > > > cond_resched(); > > > > > > /* We now go into synchronous reclaim */ > > > cpuset_memory_pressure_bump(); > > > - psi_memstall_enter(&pflags); > > > fs_reclaim_acquire(gfp_mask); > > > noreclaim_flag = memalloc_noreclaim_save(); > > > > > > @@ -4610,7 +4609,6 @@ __perform_reclaim(gfp_t gfp_mask, unsigned int order, > > > > > > memalloc_noreclaim_restore(noreclaim_flag); > > > fs_reclaim_release(gfp_mask); > > > - psi_memstall_leave(&pflags); > > > > > > cond_resched(); > > > > > > @@ -4624,11 +4622,13 @@ __alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned int order, > > > unsigned long *did_some_progress) > > > { > > > struct page *page = NULL; > > > + unsigned long pflags; > > > bool drained = false; > > > > > > + psi_memstall_enter(&pflags); > > > *did_some_progress = __perform_reclaim(gfp_mask, order, ac); > > > if (unlikely(!(*did_some_progress))) > > > - return NULL; > > > + goto out; > > > > > > retry: > > > page = get_page_from_freelist(gfp_mask, order, alloc_flags, ac); > > > @@ -4644,6 +4644,8 @@ __alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned int order, > > > drained = true; > > > goto retry; > > > } > > > +out: > > > + psi_memstall_leave(&pflags); > > > > > > return page; > > > } > > > -- > > > 2.35.1.473.g83b2b277ed-goog > > > > -- > > Michal Hocko > > SUSE Labs > > > > -- > > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. > >