From: David Hildenbrand <david@redhat.com>
To: Michal Hocko <mhocko@kernel.org>,
Scott Cheloha <cheloha@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org,
"Rafael J. Wysocki" <rafael@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
nathanl@linux.ibm.com, ricklind@linux.vnet.ibm.com,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v3] drivers/base/memory.c: cache blocks in radix tree to accelerate lookup
Date: Wed, 8 Jan 2020 14:36:48 +0100 [thread overview]
Message-ID: <890c1d43-b5c6-e126-c228-cb8c062df654@redhat.com> (raw)
In-Reply-To: <20200107214801.GN32178@dhcp22.suse.cz>
On 07.01.20 22:48, Michal Hocko wrote:
> [Cc Andrew]
>
> On Tue 17-12-19 13:32:38, Scott Cheloha wrote:
>> Searching for a particular memory block by id is slow because each block
>> device is kept in an unsorted linked list on the subsystem bus.
>
> Noting that this is O(N^2) would be useful.
>
>> Lookup is much faster if we cache the blocks in a radix tree.
>
> While this is really easy and straightforward, is there any reason why
> subsys_find_device_by_id has to use such a slow lookup? I suspect nobody
> simply needed a more optimized data structure for that purpose yet.
> Would it be too hard to use radix tree for all lookups rather than
> adding a shadow copy for memblocks?
As reply to v1/v2 I argued that this is really only needed if there are
many devices. So far that seems to be applicable to the memory subsystem
mostly. No need to waste space on all other subsystems IMHO.
As you said, right now it's easy and straightforward, if we find out
other subsystems need it we can generalize/factor out.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2020-01-08 13:36 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-20 19:25 [PATCH] memory subsystem: cache memory " Scott Cheloha
2019-11-21 9:34 ` David Hildenbrand
2019-11-21 9:35 ` David Hildenbrand
2019-11-21 19:59 ` [PATCH v2] drivers/base/memory.c: cache " Scott Cheloha
2019-11-25 6:36 ` kbuild test robot
2019-12-17 19:32 ` [PATCH v3] " Scott Cheloha
2019-12-18 9:00 ` David Hildenbrand
2019-12-19 17:33 ` Scott Cheloha
2019-12-20 10:50 ` David Hildenbrand
2019-12-19 18:09 ` Nathan Lynch
2020-01-07 21:48 ` Michal Hocko
2020-01-08 13:36 ` David Hildenbrand [this message]
2020-01-08 14:21 ` Michal Hocko
2020-01-08 15:23 ` David Hildenbrand
2020-01-09 8:49 ` Michal Hocko
2020-01-09 8:56 ` Greg Kroah-Hartman
2020-01-09 9:19 ` Michal Hocko
2020-01-09 9:24 ` David Hildenbrand
2020-01-09 9:31 ` David Hildenbrand
2020-01-09 9:41 ` Greg Kroah-Hartman
2020-01-09 9:33 ` Greg Kroah-Hartman
2020-01-09 9:50 ` Michal Hocko
2020-01-09 9:48 ` Michal Hocko
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=890c1d43-b5c6-e126-c228-cb8c062df654@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cheloha@linux.vnet.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@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®