Re: per-cpu thoughts

[Nick Kossifidis <mick@ics.forth.gr>]

Στις 2019-02-22 17:04, Christopher Lameter έγραψε:
> On Thu, 21 Feb 2019, Palmer Dabbelt wrote:
> 
>> That said, it's all a moot point here: our LR/SC instructions are part 
>> of the
>> A extension, so if you have those you have AMOs.  The general policy 
>> here is
>> that if there is an AMO that efficiently implements what you're 
>> looking for
>> then it should be preferred to an LR/SC sequence.  This specific case 
>> is
>> actually one of the places where AMOs have a big benefit as opposed to 
>> LR/SC
>> sequences, with the AMO implementation looking roughly like
>> 
>>    li t0, 1
>>    la t1, counter
>>    amoadd.w zero, t0, 0(t1)
> 
> Can you add a register that contains the per cpu area address for the
> current hardware thread in amoadd?
> 
> If we do not disable interrupts and preemption then the instruction 
> could
> be executed on any processor since the OS may preempt and reschedule 
> the
> kernel thread arbitrarily. We need a global register that contains the 
> per
> cpu area address (which is different for every hardware thread). If the
> instruction is rescheduled on a different thread then the other offset
> needs to be used so the instruction need to specify that the addres is
> relative to that global register.
> 
> PowerPC uses such a global register. On Intel the GS segment register 
> is
> abused for that purpose.
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

How about the scratch registers defined on priv spec ? We already use 
sscratch on Linux for keeping per-hart kernel data structures (check out 
entry.S) and mscratch on OpenSBI for keeping per-hart state etc.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv