[PATCH 1/1] lib: sbi: relax scoldboot_lock spinlock

Jessica Clarke jrtc27 at jrtc27.com
Thu Aug 13 14:59:55 EDT 2020


On 13 Aug 2020, at 19:53, Sean Anderson <seanga2 at gmail.com> wrote:
> On 8/13/20 2:44 PM, Jessica Clarke wrote:
>> On 13 Aug 2020, at 19:37, Jessica Clarke <jrtc27 at jrtc27.com> wrote:
>>> On 13 Aug 2020, at 19:31, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>> Because there's global state to set up. You can't have all the other
>>> harts rampaging through memory reading and writing whatever they like
>>> until they can guarantee that the primary hart has performed all the
>>> necessary initialisation for them to be able to roam free. I understand
>>> you are trying to help and offer solutions, but it is getting rather
>>> tedious to deal with what is now the third fundamentally broken patch
>>> based on a lack of understanding, so please try to listen to us and
>>> work with us to fix the problem you are facing rather than continuing
>>> to play doctor and concoct your own broken "fixes".
>> 
>> Apologies, on closer inspection this does "fix" the problem as I had
>> neglected the change to coldboot_lock's initialisation state. Yeah, it
>> works, but, no, initialising a lock to be locked on boot is not good.
>> All you've done is replace coldboot_done with !coldboot_lock (and made
>> the latter play double-duty). This is hard to follow and just asking
>> for mistakes to happen because it's not a normal thing to do.
>> 
>> Also, by doing this, you've now made all the harts busy-wait the entire
>> time rather than be able to execute WFI until the primary hart is done,
>> as they will be spinning for ages on the lock.
> 
> Why does this matter? This code will run for far less than a second,
> once per boot. Any energy savings in OpenSBI will be trivial,
> especially when compared to later boot stages.

These things are ultimately subjective, and everyone on this list
probably has slightly different opinions. But in general, why use
inefficient code when you can just as easily write more efficient code,
especially when the inefficient code is harder to reason about and more
error-prone?

Jess




More information about the opensbi mailing list