linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Breno Leitao <leitao@debian.org>
To: Michael Neuling <mikey@neuling.org>, linuxppc-dev@lists.ozlabs.org
Cc: ldufour@linux.vnet.ibm.com, gromero@linux.vnet.ibm.com
Subject: Re: [RFC PATCH 09/11] powerpc/tm: Do not restore default DSCR
Date: Thu, 27 Sep 2018 17:51:10 -0300	[thread overview]
Message-ID: <11f2155f-eff8-2aac-ab47-1ab343d52107@debian.org> (raw)
In-Reply-To: <10da0fdc641b05ea288890a23aa01ad33f2d6987.camel@neuling.org>

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

  reply	other threads:[~2018-09-27 21:11 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-12 19:40 [RFC PATCH 00/11] New TM Model Breno Leitao
2018-09-12 19:40 ` [RFC PATCH 01/11] powerpc/tm: Reclaim transaction on kernel entry Breno Leitao
2018-09-18  1:31   ` Michael Neuling
2018-09-27 20:28     ` Breno Leitao
2018-09-27 20:28       ` Breno Leitao
2018-09-12 19:40 ` [RFC PATCH 02/11] powerpc/tm: Reclaim on unavailable exception Breno Leitao
2018-09-12 19:40 ` [RFC PATCH 03/11] powerpc/tm: Recheckpoint when exiting from kernel Breno Leitao
2018-09-12 19:40 ` [RFC PATCH 04/11] powerpc/tm: Always set TIF_RESTORE_TM on reclaim Breno Leitao
2018-09-12 19:40 ` [RFC PATCH 05/11] powerpc/tm: Function that updates the failure code Breno Leitao
2018-09-17  5:29   ` Michael Neuling
2018-09-18  1:29   ` Michael Neuling
2018-09-27 20:58     ` Breno Leitao
2018-09-28  5:27       ` Michael Neuling
2018-09-18  3:27   ` Michael Neuling
2018-09-12 19:40 ` [RFC PATCH 06/11] powerpc/tm: Refactor the __switch_to_tm code Breno Leitao
2018-09-18  4:04   ` Michael Neuling
2018-09-27 20:48     ` Breno Leitao
2018-09-12 19:40 ` [RFC PATCH 07/11] powerpc/tm: Do not recheckpoint at sigreturn Breno Leitao
2018-09-18  5:32   ` Michael Neuling
2018-09-12 19:40 ` [RFC PATCH 08/11] powerpc/tm: Do not reclaim on ptrace Breno Leitao
2018-09-18  5:36   ` Michael Neuling
2018-09-27 21:03     ` Breno Leitao
2018-09-28  5:36       ` Michael Neuling
2018-09-30 23:51         ` Breno Leitao
2018-10-01  0:34           ` Michael Neuling
2018-09-12 19:40 ` [RFC PATCH 09/11] powerpc/tm: Do not restore default DSCR Breno Leitao
2018-09-18  5:41   ` Michael Neuling
2018-09-27 20:51     ` Breno Leitao [this message]
2018-09-28  5:03       ` Michael Neuling
2018-09-12 19:40 ` [RFC PATCH 10/11] powerpc/tm: Set failure summary Breno Leitao
2018-09-18  5:50   ` Michael Neuling
2018-09-27 20:52     ` Breno Leitao
2018-09-28  5:17       ` Michael Neuling
2018-09-12 19:40 ` [RFC PATCH 11/11] selftests/powerpc: Adapt the test Breno Leitao
2018-09-18  6:36   ` Michael Neuling
2018-09-27 20:57     ` Breno Leitao
2018-09-28  5:25       ` Michael Neuling
2018-10-01 17:50         ` Breno Leitao
2018-09-17  5:25 ` [RFC PATCH 00/11] New TM Model Michael Neuling
2018-09-27 20:13   ` Breno Leitao
2018-09-27 20:13     ` Breno Leitao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=11f2155f-eff8-2aac-ab47-1ab343d52107@debian.org \
    --to=leitao@debian.org \
    --cc=gromero@linux.vnet.ibm.com \
    --cc=ldufour@linux.vnet.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mikey@neuling.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).