Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp2908562ybh; Mon, 16 Mar 2020 12:02:11 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuj3ByG4ftoFdqpeU04cs2ToA6RzxGe9ouCS62AbmWnqIlIIngxi6CvjejXkJdmtk1yCBXc X-Received: by 2002:aca:c78e:: with SMTP id x136mr723770oif.116.1584385331827; Mon, 16 Mar 2020 12:02:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584385331; cv=none; d=google.com; s=arc-20160816; b=JiB0Jh5wfuvRwP9d96uG2UntYDNGYYexkbUvKhuesG++C7fQkVW5uyt6sqL8G21o34 FriWwwcn9niZkqNT1Ew4lFdWPSqmH51t4QfYLOOuEzRVx1Y05WzCXXkB+8G0cmPjXSsG orrSSETOpthXwxGn0iLvxYGd9Xw5nVPSPs4k99xMhLUhi2UJ3RitkKFVel5KQfxyrzmU smQjnmY2yBm2Ao1elEdl/V1PNi5+vh60kXGINQ4wlXf1Z1YQrHbmonRStSMr5mKcwdUV Qt8f8Y4HniT14Yw67zG53Gyc8zY2C4tcZN1RHwSREzNIt6HPKw3milExwHjz1bBGcgMv bpXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=HxTKSOvgUOiunXWoRBv/B2Z7h4ruhPTXY9TKT0CleYA=; b=N0xwh4xPzmeN5RyS3iI2XQsI/Y2pgfu18BYFBmVcStE5uZCy4o2+rUl/e67klmkScg U9E593rLLBUtQPpnmubh7jlEK0cTLa23NyTC4k28te0rGlmtyBEJ5wwZieg14/RS8LD8 Q9KYOpYs+giVJTyqdoa2vcyfRSO/dYgdqQW3TqTs8iLTh/Sm/N1Vd/jvjtKROTlOUZEn YjujBg69PA+Cas71wJRtaVX6nBds0Y/ANMaBnlk8PpGBXt2RtRZeYn5fpUJg4144T5kq yhn5K+W7GuYIiKugSLcxGuOyp8MgsWWmf8SbQCA2pfzzZ5G+oT6Vy4xPuKabygVq/BqQ +Pdw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=wUviD9a6; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v22si391411oiv.55.2020.03.16.12.01.46; Mon, 16 Mar 2020 12:02:11 -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=@joelfernandes.org header.s=google header.b=wUviD9a6; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732392AbgCPTBT (ORCPT + 99 others); Mon, 16 Mar 2020 15:01:19 -0400 Received: from mail-il1-f195.google.com ([209.85.166.195]:43572 "EHLO mail-il1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732375AbgCPTBT (ORCPT ); Mon, 16 Mar 2020 15:01:19 -0400 Received: by mail-il1-f195.google.com with SMTP id d14so17096444ilq.10 for ; Mon, 16 Mar 2020 12:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HxTKSOvgUOiunXWoRBv/B2Z7h4ruhPTXY9TKT0CleYA=; b=wUviD9a6EGTxXU9AdwBEFKOwuYqXJaMWPu5tcBHvWKXCA8xOerYMxs5dEk+DD612ve a6kOTk6g+5MJzUQKuzLLmkFV5//DsseJgYzJu4IoLIKV2YpUd422mcx+37hqDtu5wRbL MC+zNM4oYZqUyoBR87akHvnE1lcaGj7XCJ010= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HxTKSOvgUOiunXWoRBv/B2Z7h4ruhPTXY9TKT0CleYA=; b=YHJ6L7X6ZLeSQvNrI0SbndZri5q9AJgWN78eTvqFUYEzSOjMM9aB5gs+rFZEMzfPYf t/FrB0DFAzLK6maBu927+GoIopFrfir+5Ehjcw/tU4FDfdCTgTBfVcHOT2YAfGXqprDb Y3mev5chCReTG2d9hFOElpMFhdaFRpxAsL2pLJaG2Y/V4k4Lx7FRpAtt2JnXmGzX+NZ7 P8t6A6ah3gtKexiTR1qWAtYUqmPy5O6NTW0R8RKAJxLSWEL2GKclvuqMcVHTIqcwdo8X go19vLc5EYyFcauONx1IiiFl23J0wE5ITFOhtx7L7vE7zvWauC1OTBKda482w5pTucDv J6Mg== X-Gm-Message-State: ANhLgQ2iZ6SRmf9ScFq6xwu+JqVRh+SXWkmbrMcF1rmdMiYH9ffxKoi5 Uq/Ye2q4/Tk/ye8hRiYJ2gZ6wKgONZVvjVXegskxb1ZmcmE= X-Received: by 2002:a92:1e0e:: with SMTP id e14mr1321061ile.13.1584385277045; Mon, 16 Mar 2020 12:01:17 -0700 (PDT) MIME-Version: 1.0 References: <20200315181840.6966-1-urezki@gmail.com> <20200315181840.6966-3-urezki@gmail.com> <20200316154539.GE190951@google.com> <20200316185519.GA10577@pc636> In-Reply-To: From: Joel Fernandes Date: Mon, 16 Mar 2020 15:01:05 -0400 Message-ID: Subject: Re: [PATCH v1 2/6] rcu: introduce kvfree_rcu() interface To: Uladzislau Rezki Cc: LKML , "Paul E . McKenney" , RCU , Andrew Morton , Steven Rostedt , Oleksiy Avramchenko Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 16, 2020 at 2:57 PM Joel Fernandes wrote: > > On Mon, Mar 16, 2020 at 2:55 PM Uladzislau Rezki wrote: > > > > On Mon, Mar 16, 2020 at 11:45:39AM -0400, Joel Fernandes wrote: > > > On Sun, Mar 15, 2020 at 07:18:36PM +0100, Uladzislau Rezki (Sony) wrote: > > > > kvfree_rcu() can deal with an allocated memory that is obtained > > > > via kvmalloc(). It can return two types of allocated memory or > > > > "pointers", one can belong to regular SLAB allocator and another > > > > one can be vmalloc one. It depends on requested size and memory > > > > pressure. > > > > > > > > Based on that, two streams are split, thus if a pointer belongs > > > > to vmalloc allocator it is queued to the list, otherwise SLAB > > > > one is queued into "bulk array" for further processing. > > > > > > > > The main reason of such splitting is: > > > > a) to distinguish kmalloc()/vmalloc() ptrs; > > > > b) there is no vmalloc_bulk() interface. > > > > > > > > As of now we have list_lru.c user that needs such interface, > > > > also there will be new comers. Apart of that it is preparation > > > > to have a head-less variant later. > > > > > > > > Signed-off-by: Uladzislau Rezki (Sony) > > > > --- > > > > include/linux/rcupdate.h | 9 +++++++++ > > > > kernel/rcu/tiny.c | 3 ++- > > > > kernel/rcu/tree.c | 17 ++++++++++++----- > > > > 3 files changed, 23 insertions(+), 6 deletions(-) > > > > > > > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h > > > > index 2be97a83f266..bb270221dbdc 100644 > > > > --- a/include/linux/rcupdate.h > > > > +++ b/include/linux/rcupdate.h > > > > @@ -845,6 +845,15 @@ do { \ > > > > __kfree_rcu(&((___p)->rhf), offsetof(typeof(*(ptr)), rhf)); \ > > > > } while (0) > > > > > > > > +/** > > > > + * kvfree_rcu() - kvfree an object after a grace period. > > > > + * @ptr: pointer to kvfree > > > > + * @rhf: the name of the struct rcu_head within the type of @ptr. > > > > + * > > > > + * Same as kfree_rcu(), just simple alias. > > > > + */ > > > > +#define kvfree_rcu(ptr, rhf) kfree_rcu(ptr, rhf) > > > > + > > > > /* > > > > * Place this after a lock-acquisition primitive to guarantee that > > > > * an UNLOCK+LOCK pair acts as a full barrier. This guarantee applies > > > > diff --git a/kernel/rcu/tiny.c b/kernel/rcu/tiny.c > > > > index dd572ce7c747..4b99f7b88bee 100644 > > > > --- a/kernel/rcu/tiny.c > > > > +++ b/kernel/rcu/tiny.c > > > > @@ -23,6 +23,7 @@ > > > > #include > > > > #include > > > > #include > > > > +#include > > > > > > > > #include "rcu.h" > > > > > > > > @@ -86,7 +87,7 @@ static inline bool rcu_reclaim_tiny(struct rcu_head *head) > > > > rcu_lock_acquire(&rcu_callback_map); > > > > if (__is_kfree_rcu_offset(offset)) { > > > > trace_rcu_invoke_kfree_callback("", head, offset); > > > > - kfree((void *)head - offset); > > > > + kvfree((void *)head - offset); > > > > rcu_lock_release(&rcu_callback_map); > > > > return true; > > > > } > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > > > > index 2f4c91a3713a..1c0a73616872 100644 > > > > --- a/kernel/rcu/tree.c > > > > +++ b/kernel/rcu/tree.c > > > > @@ -2899,9 +2899,9 @@ static void kfree_rcu_work(struct work_struct *work) > > > > } > > > > > > > > /* > > > > - * Emergency case only. It can happen under low memory > > > > - * condition when an allocation gets failed, so the "bulk" > > > > - * path can not be temporary maintained. > > > > + * vmalloc() pointers end up here also emergency case. It can > > > > > > Suggest rephrase for clarity: > > > > > > nit: We can end up here either with 1) vmalloc() pointers or 2) low on memory > > > and could not allocate a bulk array. > > > > > Let's go with your suggestion. I see that you took patches to your tree. > > Could you please update it on your own? Otherwise i can send out V2, so > > please let me know. > > I updated it, "patch -p1" resolved the issue. No need to resend unless > something in my tree looks odd to you :) I added this: diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0e2632622176b..e7963270e7f6a 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -2857,9 +2857,10 @@ static void kfree_rcu_work(struct work_struct *work) } /* - * vmalloc() pointers end up here also emergency case. It can - * happen under low memory condition when an allocation gets - * failed, so the "bulk" path can not be temporary maintained. + * We can end up here either with 1) vmalloc() pointers or 2) were low + * on memory and could not allocate a bulk array. It can happen under + * low memory condition when an allocation gets failed, so the "bulk" + * path can not be temporarly used. */ for (; head; head = next) { unsigned long offset = (unsigned long)head->func; Thanks.