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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9EBE9C4727F for ; Wed, 30 Sep 2020 15:52:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0405F207C3 for ; Wed, 30 Sep 2020 15:52:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=joelfernandes.org header.i=@joelfernandes.org header.b="WV//9SwE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0405F207C3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=joelfernandes.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 65D26900002; Wed, 30 Sep 2020 11:52:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60C068E0001; Wed, 30 Sep 2020 11:52:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D436900002; Wed, 30 Sep 2020 11:52:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0197.hostedemail.com [216.40.44.197]) by kanga.kvack.org (Postfix) with ESMTP id 30FF38E0001 for ; Wed, 30 Sep 2020 11:52:32 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E31411803E8C5 for ; Wed, 30 Sep 2020 15:52:31 +0000 (UTC) X-FDA: 77320170102.04.walk52_2b10a3c27194 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id A8EDF80118E2 for ; Wed, 30 Sep 2020 15:52:31 +0000 (UTC) X-HE-Tag: walk52_2b10a3c27194 X-Filterd-Recvd-Size: 5350 Received: from mail-qv1-f67.google.com (mail-qv1-f67.google.com [209.85.219.67]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Wed, 30 Sep 2020 15:52:31 +0000 (UTC) Received: by mail-qv1-f67.google.com with SMTP id j10so1122388qvk.11 for ; Wed, 30 Sep 2020 08:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=U5B+DFlgjUCfVVr9Dz8Mt+RPlNdJaSsb6hueCXdN2UY=; b=WV//9SwE2q/r9XyXsDlPrOuIcGjLmuR66fo/ASIwZL/CGda9BpAxGw2XIKpOXFnqCe Kfxr0Y/Rsrf9vK5Hk7HiH/Gy180JQ6PJjs1bVknOi2dR/cQ4Dsblwu/EcdHVh+hckTyX iAvq4jAFbQlNbRTFkL+KvY7LQW57Fyhk+o9wI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=U5B+DFlgjUCfVVr9Dz8Mt+RPlNdJaSsb6hueCXdN2UY=; b=KKvqRkYRID3qcfvHS6cVHjUjAfIGUvgxaKS9lq2wA00cQYNRA4fmJ8rrE2R8uRWxrJ P+r2QsZ+w+AwW8bn3HdjXN1EZKz2B7JAeLaMNPMvvFiFe826bRT+lBgQ1CwTy/rlRbOc WI2PEXblvMBg4/XsPMWYgdP5y3jPqFEN/wlZS9gC/nVpDjeFu+G2WK4iN2giW6e109ab a7ByTGf9QsghydfhgPvg/+qwKVzBYdwPPQtngN+Vt2BbMiw94MlHviXCuNpo1Efqoe9U L4o9fdIPQRzncdsThXiCaMXa1Hs4ab+04R44ez7Vr2NP8QDz77cZvaAkfZU/psfUphaM NfUQ== X-Gm-Message-State: AOAM532BwhIpMaS5wdd7uiFYovXYepovdX7IdOIoXOsyX3lI3p/P1NIC Tq7mrwuPNh5uvMFQc0PIhWSnVg== X-Google-Smtp-Source: ABdhPJxCHYn12FbypuTQ8FDk+s5B8QbO2utbnkuTv/k8oQUR5DMg5bq76vbefymLnwGGqLe6TcQGaA== X-Received: by 2002:a0c:eda3:: with SMTP id h3mr2867524qvr.61.1601481150585; Wed, 30 Sep 2020 08:52:30 -0700 (PDT) Received: from localhost ([2620:15c:6:12:cad3:ffff:feb3:bd59]) by smtp.gmail.com with ESMTPSA id 206sm2591725qkk.27.2020.09.30.08.52.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Sep 2020 08:52:29 -0700 (PDT) Date: Wed, 30 Sep 2020 11:52:29 -0400 From: Joel Fernandes To: "Uladzislau Rezki (Sony)" Cc: LKML , RCU , linux-mm@kvack.org, Andrew Morton , "Paul E . McKenney" , Peter Zijlstra , Michal Hocko , Vlastimil Babka , Thomas Gleixner , "Theodore Y . Ts'o" , Sebastian Andrzej Siewior , Oleksiy Avramchenko Subject: Re: [PATCH 0/4] kvfree_rcu() and _LOCK_NESTING/_PREEMPT_RT Message-ID: <20200930155229.GA1474760@google.com> References: <20200918194817.48921-1-urezki@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200918194817.48921-1-urezki@gmail.com> 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 Fri, Sep 18, 2020 at 09:48:13PM +0200, Uladzislau Rezki (Sony) wrote: > Hello, folk! > > This is another iteration of fixing kvfree_rcu() issues related > to CONFIG_PROVE_RAW_LOCK_NESTING and CONFIG_PREEMPT_RT configs. > > The first discussion is here https://lkml.org/lkml/2020/8/9/195. > > - As an outcome of it, there was a proposal from Peter, instead of > using a speciall "lock-less" flag it is better to move lock-less > access to the pcplist to the separate function. > > - To add a special worker thread that does prefetching of pages > if a per-cpu page cache is depleted(what is absolutely normal). > > As usual, thank you for paying attention to it and your help! Doesn't making it a lower priority WQ exacerbate the problem Mel described? So like: 1. pcp cache is depleted by kvfree_rcu without refill or other measures to relieve memory. 2. now other GFP_ATOMIC users could likely hit the emergency reserves in the buddy allocator as the watermarks are crossed. 3. kvfree_rcu() notices failure and queues workqueue to do non-preemptible buddy allocations which will refill the pcp cache in the process. 4. But that happens much later because this patch (4/4) down prioritized the work to do the refill. I'd suggest keeping it high pri since I don't see how it can make things better. Or another option is: Why not just hit the fallback path in the caller on the first attempt, and trigger the WQ to do the allocation. If the pool grows too big, we can have shrinkers that free memory that is excessive so that will help the phone usecases. That way no changes to low-level allocator are needed. Or did I miss something? thanks, - Joel > > Uladzislau Rezki (Sony) (4): > rcu/tree: Add a work to allocate pages from regular context > mm: Add __rcu_alloc_page_lockless() func. > rcu/tree: use __rcu_alloc_page_lockless() func. > rcu/tree: Use schedule_delayed_work() instead of WQ_HIGHPRI queue > > include/linux/gfp.h | 1 + > kernel/rcu/tree.c | 90 ++++++++++++++++++++++++--------------------- > mm/page_alloc.c | 82 +++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 132 insertions(+), 41 deletions(-) > > -- > 2.20.1 >