Re: [PATCH RFC 1/4] lib/radix: add universal radix_tree_fill_range

From: Dan Williams
Date: Tue Aug 30 2016 - 17:56:31 EST


On Mon, Aug 29, 2016 at 11:52 AM, Matthew Wilcox <mawilcox@xxxxxxxxxxxxx> 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'd use a fill range api for the radix backing get_dev_pagemap() and
potentially another use in device-dax. It centralizes the common
routine of breaking down a range into its constituent power-of-2
ranges.