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=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 B2FCCC4360C for ; Fri, 4 Oct 2019 17:20:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 846352084D for ; Fri, 4 Oct 2019 17:20:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=joelfernandes.org header.i=@joelfernandes.org header.b="DLw0gUoD" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730070AbfJDRUl (ORCPT ); Fri, 4 Oct 2019 13:20:41 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:37558 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729291AbfJDRUl (ORCPT ); Fri, 4 Oct 2019 13:20:41 -0400 Received: by mail-pf1-f194.google.com with SMTP id y5so4289354pfo.4 for ; Fri, 04 Oct 2019 10:20:40 -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:user-agent; bh=CFABRMz1edgqMZrdkcJ5grQHuov7IQWx4KDvNWdkveo=; b=DLw0gUoDjdWvEBBUV5C8SsFx2SjR7VbPltgBwhUofYZDeym6mWGlcy4pzCTH99BHOv kKM6IrnZhzr87BifF8O22/Xjqa10WR/Uyac9x7SQG4iz4uVReP6nlGz+d6b0T+xjQvPL Z11qFIqBDxRwx+WWICguoP64fiLb15pZr6PQo= 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:user-agent; bh=CFABRMz1edgqMZrdkcJ5grQHuov7IQWx4KDvNWdkveo=; b=oTSp1CWaWu9MEDDo/UOL3r0ITVrLKDMP72PHKLLQqMzDmidpKtz2By0JsQmyPBpPF9 Ko+Kf9BJi17oTTfvxBHw1ysh371//X2tylvVVGN2fVfIlvndla7pVm71qyWlMSz9+1VI ewPvYo5eAquXOK4HSdv22LY3Or1OnP66Xk1i0AHpnVE7scebSltaFaCq6dZxMxIDDvDF EIwUnnXZUY8HMqdG1oirXW/Zi3fSH8xDn1CvA3IIycyUSZDbirQI+AsHRCO4IUkZ+RzZ R45Lui6Vmz5KeYcFAqDx0r1WmkU0yMRiD0SSME/TQvd8p/5YXFAQfJCyb4ztub0IT79z khxQ== X-Gm-Message-State: APjAAAViLwMqXXO78fB0KIgwMoxPbRE1DT0qPsR+lSvCvPIiRXOugiKz yh3N2jWqzzeNdLISTHVSzxGOrQ== X-Google-Smtp-Source: APXvYqwFCmRx7gnHvoTWyC7aMhsw0IcKe/Dj+u7BUgTEzw2ALpPH5rZ3jH7F7dZ7Yuhc2QYnthap5Q== X-Received: by 2002:a62:a509:: with SMTP id v9mr17803603pfm.180.1570209640112; Fri, 04 Oct 2019 10:20:40 -0700 (PDT) Received: from localhost ([2620:15c:6:12:9c46:e0da:efbf:69cc]) by smtp.gmail.com with ESMTPSA id j22sm8832861pgg.16.2019.10.04.10.20.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Oct 2019 10:20:39 -0700 (PDT) Date: Fri, 4 Oct 2019 13:20:38 -0400 From: Joel Fernandes To: Uladzislau Rezki Cc: linux-kernel@vger.kernel.org, kernel-team@android.com, kernel-team@lge.com, Byungchul Park , Davidlohr Bueso , Josh Triplett , Lai Jiangshan , Mathieu Desnoyers , max.byungchul.park@gmail.com, "Paul E. McKenney" , Rao Shoaib , rcu@vger.kernel.org, Steven Rostedt Subject: Re: [PATCH v4 1/2] rcu/tree: Add basic support for kfree_rcu() batching Message-ID: <20191004172038.GG253167@google.com> References: <20190814160411.58591-1-joel@joelfernandes.org> <20190918095811.GA25821@pc636> <20190930201623.GA134859@google.com> <20191001112702.GA22112@pc636> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191001112702.GA22112@pc636> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: rcu-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: rcu@vger.kernel.org On Tue, Oct 01, 2019 at 01:27:02PM +0200, Uladzislau Rezki wrote: [snip] > > > I have just a small question related to workloads and performance evaluation. > > > Are you aware of any specific workloads which benefit from it for example > > > mobile area, etc? I am asking because i think about backporting of it and > > > reuse it on our kernel. > > > > I am not aware of a mobile usecase that benefits but there are server > > workloads that make system more stable in the face of a kfree_rcu() flood. > > > OK, i got it. I wanted to test it finding out how it could effect mobile > workloads. > > > > > For the KVA allocator work, I see it is quite similar to the way binder > > allocates blocks. See function: binder_alloc_new_buf_locked(). Is there are > > any chance to reuse any code? For one thing, binder also has an rbtree for > > allocated blocks for fast lookup of allocated blocks. Does the KVA allocator > > not have the need for that? > > > Well, there is a difference. Actually the free blocks are not sorted by > the its size like in binder layer, if understand the code correctly. > > Instead, i keep them(free blocks) sorted(by start address) in ascending > order + maintain the augment value(biggest free size in left or right sub-tree) > for each node, that allows to navigate toward the lowest address and the block > that definitely suits. So as a result our allocations become sequential > what is important. Right, I realized this after sending the email that binder and kva sort differently though they both try to use free sizes during the allocation. Would you have any papers, which survey various rb-tree based allocator algorithms and their tradeoffs? I am interested in studying these more especially in relation to the binder driver. Would also be nice to make contributions to papers surveying both these allocators to describe the state of the art. thanks, - Joel > > > > And, nice LPC presentation! I was there ;) > > > Thanks :) > > -- > Vlad Rezki