Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1706654ybb; Thu, 2 Apr 2020 06:00:39 -0700 (PDT) X-Google-Smtp-Source: APiQypJpTRMLFcvgwYwwi7lDCUcPxROHqmpxNBLuvpbfNN/KaCTyBKRWgQ5VCbYkXE2EPUb5VYjY X-Received: by 2002:aca:cf87:: with SMTP id f129mr1970630oig.109.1585832439173; Thu, 02 Apr 2020 06:00:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585832439; cv=none; d=google.com; s=arc-20160816; b=y4/QXKyORqQjc2WFIBufvydF25uZClVddpV65cDJrvbxm+XOv+0BVx7dFDEeSdTFY1 4LGXBiBlb0le/bMosufjA/vbJmtGjOjZNpRaOgEwWp2C8dn2N8t37Xfm51J7fPGx50lQ NvQIsOLi9C2k8q6pRY6hHsERvsI0+qhwBMWmxgivoazUJae7fRCENs2ZeSOyKLJ7HkER WavlY+ON8zSbE26pYL3vyu/Q9eZHQrNgoou9hUr+skyMzr/fc14cX0csF3pCiJQpBCfo BY4RwVKXJ1CnXJSNtwXLaPynVCK0JbbowhBwTFr+wsvjTxlPnrOC2zqzo/Phv5bb3fYW wRHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=l3xG+lzh6Q2m2bU1b/cZLY6stz0OrJ21NrAPdv3f5lI=; b=LIHw7uhLDfQjpAOhP9tiBcTmm4hJQrOEAFI8hLDX9h3ubagHHkxArxBGNts3/YKdJX K9EA1BQ+Pf503z66tA03rXiTOdeCxZPF9HyBGi7h9JCHNLP9+3Vdav+bl4FNK1iMF0Lu 3MYtFFGLDtBO7d4CZdwkLfVj5Ze0Dp+erTNFL8nrzddo4BdUo+0ULslFkGHAtHNb5n/H tdEWQY80IHvPA9on//NyHtSAJauc0cSRtE73dj2ObGiL74J89vMDumDda2fVd2CsowCm FqCuwIb6h+3TdXdlnE965oFWnTpX5ZOdnNeDJCPiD8C9ZE62B4G9Wx600/1z352HiI2x jTkQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=YdCj68Co; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p67si2314620oig.41.2020.04.02.06.00.25; Thu, 02 Apr 2020 06:00:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=YdCj68Co; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387891AbgDBMdG (ORCPT + 99 others); Thu, 2 Apr 2020 08:33:06 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:46638 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729213AbgDBMdG (ORCPT ); Thu, 2 Apr 2020 08:33:06 -0400 Received: by mail-lj1-f195.google.com with SMTP id r7so2975945ljg.13; Thu, 02 Apr 2020 05:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=l3xG+lzh6Q2m2bU1b/cZLY6stz0OrJ21NrAPdv3f5lI=; b=YdCj68CoIGNm8klzekN6UwRYTOMrJXNAezwvbdvUizysC4JClKGycqepTK+P7kMSvz uwVO0pWBAXIY1nFRiH8r9VGbzeOqyH9dKdPayLKVc+dWktRsc/A/1Sov+46ZtTtRdUB/ xUJNK1/Gz3eateO4IDozVXnf1oN0EuAtjmu4VOSsRljrle+pIg2MY1gNdURCin4zU6/k SWHI1+MuowwyS8UwE8c8lJi2kBSm5o++E57IM3Er2yNVdlacfF/ktRO8zJygZVEjM92l tQHJkbf5Mij5Ekw+QVL+Gt0PzXldNxNVNJ3WuoTmVy3hWs8vAndrvhY6XDAQ5mGgF4yv 5pUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=l3xG+lzh6Q2m2bU1b/cZLY6stz0OrJ21NrAPdv3f5lI=; b=G+wVldXzC35//9/Y4ma0LnzCfBYx/39PMU07+SMC2iH2u6AOSW4XNNr1iV/+6cdN32 1r2x74kRNG+aB1Is6HgRduCfxOFFXE3XKbxszD10XHTJOdA3fLfHoLNESr6vdyvLlxru XYfFnzOEF39qq3a1syqQnHSjc7Rr0NCTcx+lcdiiWAsfGVDbcyJlWphwyUkWaY816dXG SUC1swHDY3FJeR2IEAcpa0KFEYH+LSYA2rrVgld/krtvNwIFInqVX/RHnrLnLQRLL4o7 FxpBaZQZXj2QHgmvt+kR5V1Oh6K0b9vZaqoMWx9lbCw2Q/Pfv1s7QmLIyc7boxzUJgT4 k+1Q== X-Gm-Message-State: AGi0PuZHBOLB3ETdtdUioiYWOIU5tB13lFzehKdJuppeItlW34Nb5b9m QlUzc698aRXtbLoMUaZx7Z29ZTwIpqQ= X-Received: by 2002:a2e:8887:: with SMTP id k7mr1909764lji.193.1585830783082; Thu, 02 Apr 2020 05:33:03 -0700 (PDT) Received: from pc636.lan (h5ef52e31.seluork.dyn.perspektivbredband.net. [94.245.46.49]) by smtp.gmail.com with ESMTPSA id u25sm3833494lfo.71.2020.04.02.05.33.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Apr 2020 05:33:01 -0700 (PDT) From: "Uladzislau Rezki (Sony)" To: LKML , "Paul E . McKenney" , Joel Fernandes Cc: RCU , linux-mm@kvack.org, Andrew Morton , Uladzislau Rezki , Steven Rostedt , Oleksiy Avramchenko Subject: [PATCH 1/3] rcu/tree: use more permissive parameters when attaching a head Date: Thu, 2 Apr 2020 14:32:51 +0200 Message-Id: <20200402123253.10382-1-urezki@gmail.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org It is documneted that a headless object can be reclaimed from might_sleep() context only. Because of that when a head is dynamically attached it makes sense to drop the lock and do an allocation with much more permissve flags comparing if it is done from atomic context. That is why use GFP_KERNEL flag plus some extra ones which would make an allocation most likely to be succeed. The big advantage of doing so is a direct reclaim process. Tested such approach on my local tiny system with 145MB of ram(the minimum amount the KVM system is capable of booting) and 4xCPUs. For stressing the rcuperf module was used. During tests with difference combinations i did not observe any hit of our last emergency case, when synchronize_rcu() is involved. Please note, the "dynamically attaching" path was enabled only, apart of that all types of objects were considered as headless variant during testing. Signed-off-by: Uladzislau Rezki (Sony) Suggested-by: Joel Fernandes (Google) --- kernel/rcu/tree.c | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 6172e6296dd7..24f620a06219 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -3148,13 +3148,10 @@ static inline struct rcu_head *attach_rcu_head_to_object(void *obj) { unsigned long *ptr; + /* Try hard to get the memory. */ ptr = kmalloc(sizeof(unsigned long *) + - sizeof(struct rcu_head), GFP_NOWAIT | __GFP_NOWARN); - - if (!ptr) - ptr = kmalloc(sizeof(unsigned long *) + - sizeof(struct rcu_head), GFP_ATOMIC | __GFP_NOWARN); - + sizeof(struct rcu_head), GFP_KERNEL | + __GFP_ATOMIC | __GFP_HIGH | __GFP_RETRY_MAYFAIL); if (!ptr) return NULL; @@ -3222,9 +3219,20 @@ void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func) if (!success) { /* Is headless object? */ if (head == NULL) { + /* Drop the lock. */ + if (krcp->initialized) + spin_unlock(&krcp->lock); + local_irq_restore(flags); + head = attach_rcu_head_to_object(ptr); if (head == NULL) - goto unlock_return; + goto inline_return; + + /* Take it back. */ + local_irq_save(flags); + krcp = this_cpu_ptr(&krc); + if (krcp->initialized) + spin_lock(&krcp->lock); /* * Tag the headless object. Such objects have a back-pointer @@ -3263,6 +3271,7 @@ void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func) spin_unlock(&krcp->lock); local_irq_restore(flags); +inline_return: /* * High memory pressure, so inline kvfree() after * synchronize_rcu(). We can do it from might_sleep() -- 2.20.1