[RFC PATCH 09/11] powerpc/tm: Do not restore default DSCR
Breno Leitao
leitao at debian.org
Fri Sep 28 06:51:10 AEST 2018
Hi Mikey,
On 09/18/2018 02:41 AM, Michael Neuling wrote:
> On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
>> In the previous TM code, trecheckpoint was being executed in the middle of
>> an exception, thus, DSCR was being restored to default kernel DSCR value
>> after trecheckpoint was done.
>>
>> With this current patchset, trecheckpoint is executed just before getting
>> to userspace, at ret_from_except_lite, for example. Thus, we do not need to
>> set default kernel DSCR value anymore, as we are leaving kernel space. It
>> is OK to keep the checkpointed DSCR value into the live SPR, mainly because
>> the transaction is doomed and it will fail soon (after RFID),
>
> What if we are going back to a suspended transaction? It will remain live until
> userspace does a tresume
Hmm, I understand that once we get in kernel space, and call
treclaim/trecheckpoint, the transaction will be doomed and it will abort and
rollback when we leave kernel space. I.e., if we can treclaim/trecheckpointn
in kernel space, the transaction will *always* abort just after RFID, so, a
possible tresume will never be executed. Is my understanding wrong?
>
>> so,
>> continuing with the pre-checkpointed DSCR value is what seems correct.
>
> Reading this description suggests this patch isn't really needed. Right?
Maybe the description is not clear, but I understand this patch is required,
otherwise we will leave userspace with a default DSCR value.
By the way, do you know if there is a change in DSCR inside a transaction,
will it be reverted if the transaction is aborted?
Thank you
More information about the Linuxppc-dev
mailing list