[PATCH v2 9/9] arm64: Work around systems with mismatched cache line sizes
Suzuki K Poulose
Suzuki.Poulose at arm.com
Fri Aug 26 06:04:50 PDT 2016
On 26/08/16 12:03, Ard Biesheuvel wrote:
> Hello Suzuki,
>
>> For faster access (i.e, avoiding to lookup the system wide value of CTR_EL0
>> via read_system_reg), we keep track of the pointer to table entry for
>> CTR_EL0 in the CPU feature infrastructure.
>>
>
> IIUC it is the runtime sorting of the arm64_ftr_reg array that
> requires you to stash a pointer to CTR_EL0's entry somewhere, so that
> you can dereference it without doing the bsearch.
Correct.
>
> IMO, this is a pattern that we should avoid: you are introducing one
> instance now, which will make it hard to say no to the next one in the
> future. Isn't there a better way to organize the arm64_ftr_reg array
> that allows us to reference entries directly? Ideally, a way that gets
> rid of the runtime sorting, since I don't think that is a good
> replacement for developer discipline anyway (although I should have
> spoken up when that was first introduced) Or am I missing something
> here?
I had some form of direct access to the feature register in one of
the versions [0], but was dropped based on Catalin's suggestion at [1].
[0] https://lkml.org/lkml/2015/10/5/504
[1] https://lkml.org/lkml/2015/10/7/558
Suzuki
More information about the linux-arm-kernel
mailing list