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
