From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1755850AbcH3WBq (ORCPT <rfc822;w@1wt.eu>);
        Tue, 30 Aug 2016 18:01:46 -0400
Received: from mga14.intel.com ([192.55.52.115]:40325 "EHLO mga14.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1754140AbcH3WAc (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 30 Aug 2016 18:00:32 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.30,258,1470726000"; 
   d="scan'208";a="872772991"
Date: Tue, 30 Aug 2016 16:00:30 -0600
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>,
        Ross Zwisler <ross.zwisler@linux.intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC 1/4] lib/radix: add universal radix_tree_fill_range
Message-ID: <20160830220030.GA20121@linux.intel.com>
References: <147230727479.9957.1087787722571077339.stgit@zurg>
 <20160827180927.GA22919@linux.intel.com>
 <DM2PR21MB0089CB40A8A9CE53A23EED50CBE10@DM2PR21MB0089.namprd21.prod.outlook.com>
 <CALYGNiPRu5ehegHcqDE=BXYHM8Wd-vz_QE8WCk0jYYKsLfiZkQ@mail.gmail.com>
 <DM2PR21MB0089143A1F6773097B21BE8FCBE10@DM2PR21MB0089.namprd21.prod.outlook.com>
 <CALYGNiO6QEhA-Oa1TT+j9CkZxz9UerrnVoZg-fV0u46FdFwQQQ@mail.gmail.com>
 <DM2PR21MB0089A76C6ACE9299CFD37938CBE10@DM2PR21MB0089.namprd21.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <DM2PR21MB0089A76C6ACE9299CFD37938CBE10@DM2PR21MB0089.namprd21.prod.outlook.com>
User-Agent: Mutt/1.7.0 (2016-08-17)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Aug 29, 2016 at 06:52:54PM +0000, Matthew Wilcox wrote:
> It may be protected by the mapping lock in the current code, but I would it
> expect it to become an RCU lookup + lock eventually.  No mapping lock, just
> like the page cache.
> 
> Even if we can work around it, why do we want to?  What's the compelling
> reason to change from the current radix tree representation of order-N
> entries to an arbitrary range?  There are no in-kernel users right now; is
> there a performance reason to change?  We don't usually change an API in
> anticipation of future users appearing, particularly when the API makes it
> harder for the existing users to use it.

I do have a patch set out for review which uses the multi-order nature of the
radix tree:

https://lkml.org/lkml/2016/8/23/725

This code takes advantage of the fact that using the radix tree for an order-0
entry is the same as for a multi-order entry.  Both have a single lock bit,
and a single entry that i need to use for lookups, sets, locking and
unlocking.

My usage fits well with the current implementation of the radix tree, and I'd
like to keep it simple if I can.