linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: Correct virt_addr_valid
Date: Wed, 11 Dec 2013 11:06:18 +0000	[thread overview]
Message-ID: <20131211110618.GG4360@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20131211104429.GE26730@mudshark.cambridge.arm.com>

On Wed, Dec 11, 2013 at 10:44:29AM +0000, Will Deacon wrote:
> Hmm, this is pretty expensive on both arm and arm64, since we end up doing a
> binary search through all of the memblocks.

People say "binary search == expensive" almost as a knee jerk
reaction, because classical thinking is that binary searches are
expensive for systems with caches.  Have you considered how many
memblocks you end up with on a normal system?

How expensive is a binary search across one element?  Two elements?
Four elements?  In the very very rare case (there's only one platform)
eight elements?

For one element, it's the same as a linear search - we only have to
look at one element and confirm whether the pointer is within range.
Same for two - we check one and check the other.  As memblock is array
based, both blocks share the same cache line.

For four, it means we look at most three elements, at least two of
which share a cache line.  In terms of cache line loading, it's no
more expensive than a linear search.  In terms of CPU cycles, it's
a win because we don't need to expend cycles looking at the fourth
element.

For eight (which is starting to get into the "rare" territory, and
three cache lines, four elements vs a linear search which can be up
to four cache lines and obviously eight elements.

Now, bear in mind that the normal case is one, there's a number with
two, four starts to become rare, and eight is almost non-existent...

  reply	other threads:[~2013-12-11 11:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-11  1:23 [PATCH] arm: Correct virt_addr_valid Laura Abbott
2013-12-11  1:23 ` [PATCH] arm64: " Laura Abbott
2013-12-11 10:44   ` Will Deacon
2013-12-11 11:06     ` Russell King - ARM Linux [this message]
2013-12-11 17:26       ` Will Deacon
2013-12-11 21:13         ` Russell King - ARM Linux
2013-12-12 17:57           ` Catalin Marinas
2013-12-12 18:02             ` Russell King - ARM Linux
2013-12-12 22:09               ` Laura Abbott
2013-12-13 11:57                 ` Catalin Marinas
2013-12-16 18:28                   ` Laura Abbott
2013-12-17 14:19                     ` Catalin Marinas
2013-12-11 17:35     ` Laura Abbott

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=20131211110618.GG4360@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).