From: Michal Hocko <mhocko@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: Scott Cheloha <cheloha@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org,
"Rafael J. Wysocki" <rafael@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
nathanl@linux.ibm.com, ricklind@linux.vnet.ibm.com,
Scott Cheloha <cheloha@linux.ibm.com>,
Donald Dutile <ddutile@redhat.com>
Subject: Re: [PATCH v4] drivers/base/memory.c: cache blocks in radix tree to accelerate lookup
Date: Fri, 17 Jan 2020 10:35:14 +0100 [thread overview]
Message-ID: <20200117093514.GO19428@dhcp22.suse.cz> (raw)
In-Reply-To: <fe92b4f0-0cd7-c705-1ed9-239175689051@redhat.com>
On Thu 16-01-20 17:17:54, David Hildenbrand wrote:
[...]
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index c6d288fad493..c75dec35de43 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -19,7 +19,7 @@
> #include <linux/memory.h>
> #include <linux/memory_hotplug.h>
> #include <linux/mm.h>
> -#include <linux/radix-tree.h>
> +#include <linux/xarray.h>
> #include <linux/stat.h>
> #include <linux/slab.h>
>
> @@ -58,11 +58,11 @@ static struct bus_type memory_subsys = {
> };
>
> /*
> - * Memory blocks are cached in a local radix tree to avoid
> + * Memory blocks are cached in a local xarray to avoid
> * a costly linear search for the corresponding device on
> * the subsystem bus.
> */
> -static RADIX_TREE(memory_blocks, GFP_KERNEL);
> +static DEFINE_XARRAY(memory_blocks);
>
> static BLOCKING_NOTIFIER_HEAD(memory_chain);
>
> @@ -566,7 +566,7 @@ static struct memory_block *find_memory_block_by_id(unsigned long block_id)
> {
> struct memory_block *mem;
>
> - mem = radix_tree_lookup(&memory_blocks, block_id);
> + mem = xa_load(&memory_blocks, block_id);
> if (mem)
> get_device(&mem->dev);
> return mem;
> @@ -621,7 +621,8 @@ int register_memory(struct memory_block *memory)
> put_device(&memory->dev);
> return ret;
> }
> - ret = radix_tree_insert(&memory_blocks, memory->dev.id, memory);
> + ret = xa_err(xa_store(&memory_blocks, memory->dev.id, memory,
> + GFP_KERNEL));
> if (ret) {
> put_device(&memory->dev);
> device_unregister(&memory->dev);
> @@ -683,7 +684,7 @@ static void unregister_memory(struct memory_block *memory)
> if (WARN_ON_ONCE(memory->dev.bus != &memory_subsys))
> return;
>
> - WARN_ON(radix_tree_delete(&memory_blocks, memory->dev.id) == NULL);
> + WARN_ON(xa_erase(&memory_blocks, memory->dev.id) == NULL);
>
> /* drop the ref. we got via find_memory_block() */
> put_device(&memory->dev);
OK, this looks sensible. xa_store shouldn't ever return an existing
device as we do the lookpup beforehand so good. We might need to
reorganize the code if we want to drop the loopup though.
Thanks!
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2020-01-17 9:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20191217193238-1-cheloha@linux.vnet.ibm.com>
2020-01-09 21:19 ` [PATCH] " Scott Cheloha
2020-01-09 21:30 ` Michal Hocko
2020-01-09 21:25 ` [PATCH v4] " Scott Cheloha
2020-01-09 22:00 ` Andrew Morton
2020-01-09 22:17 ` David Hildenbrand
2020-01-09 22:27 ` Andrew Morton
2020-01-09 22:35 ` David Hildenbrand
2020-01-10 9:32 ` David Hildenbrand
2020-01-10 11:31 ` Michal Hocko
2020-01-15 19:09 ` David Hildenbrand
2020-01-16 15:22 ` Michal Hocko
2020-01-16 15:28 ` David Hildenbrand
2020-01-16 16:17 ` David Hildenbrand
2020-01-17 9:35 ` Michal Hocko [this message]
2020-01-20 9:15 ` David Hildenbrand
2020-01-21 12:30 ` Michal Hocko
2020-01-16 17:17 ` Don Dutile
2020-01-21 23:10 ` [PATCH v5] drivers/base/memory.c: cache memory blocks in xarray " Scott Cheloha
2020-01-22 10:43 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200117093514.GO19428@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cheloha@linux.ibm.com \
--cc=cheloha@linux.vnet.ibm.com \
--cc=david@redhat.com \
--cc=ddutile@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nathanl@linux.ibm.com \
--cc=rafael@kernel.org \
--cc=ricklind@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®