[PATCH] arm64: Correct virt_addr_valid

Will Deacon will.deacon at arm.com
Wed Dec 11 12:26:35 EST 2013


On Wed, Dec 11, 2013 at 11:06:18AM +0000, Russell King - ARM Linux wrote:
> 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...

Sure, but it's going to be notably more expensive than what we currently
have. The question then is: does this code occur frequently (i.e. in a loop)
on some hot path?

Turning to grep, the answer seems to be "no", so I'll stop complaining about
a problem that we don't have :)

Will



More information about the linux-arm-kernel mailing list