[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