From: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
To: David Laight <David.Laight@ACULAB.COM>,
"mpe@ellerman.id.au" <mpe@ellerman.id.au>
Cc: "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"rusty@rustcorp.com.au" <rusty@rustcorp.com.au>,
"paulus@samba.org" <paulus@samba.org>,
"anton@samba.org" <anton@samba.org>
Subject: Re: [RFC PATCH 0/2] powerpc: CR based local atomic operation implementation
Date: Fri, 28 Nov 2014 13:57:08 +0530 [thread overview]
Message-ID: <547831DC.6000703@linux.vnet.ibm.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1C9FDC8B@AcuExch.aculab.com>
On Thursday 27 November 2014 07:35 PM, David Laight wrote:
> From: Madhavan Srinivasan
>> This patchset create the infrastructure to handle the CR based
>> local_* atomic operations. Local atomic operations are fast
>> and highly reentrant per CPU counters. Used for percpu
>> variable updates. Local atomic operations only guarantee
>> variable modification atomicity wrt the CPU which owns the
>> data and these needs to be executed in a preemption safe way.
>
> These are usually called 'restartable atomic sequences (RAS)'.
>
>> Here is the design of the first patch. Since local_* operations
>> are only need to be atomic to interrupts (IIUC), patch uses
>> one of the Condition Register (CR) fields as a flag variable. When
>> entering the local_*, specific bit in the CR5 field is set
>> and on exit, bit is cleared. CR bit checking is done in the
>> interrupt return path. If CR5[EQ] bit set and if we return
>> to kernel, we reset to start of local_* operation.
>
> I don't claim to be able to read ppc assembler.
> But I can't see the code that clears CR5[EQ] for the duration
> of the ISR.
I use crclr instruction at the end of the code block to clear the bit.
> Without it a nested interrupt will go through unwanted paths.
>
> There are also a lot of 'magic' constants in that assembly code.
>
All these constants are define in asm/ppc-opcode.h
> I also wonder if it is possible to inspect the interrupted
> code to determine the start/end of the RAS block.
> (Easiest if you assume that there is a single 'write' instruction
> as the last entry in the block.)
>
So each local_* function also have code in the __ex_table section. IIUC,
__ex_table contains two address. So if the return address found in the
first column of the _ex_table, use the corresponding address in the
second column to continue from.
> Also, how expensive is it to disable all interrupts?
>
In the patch 1/2, posted the numbers for that too.
> David
>
Regards
Maddy
next prev parent reply other threads:[~2014-11-28 8:27 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 12:18 [RFC PATCH 0/2] powerpc: CR based local atomic operation implementation Madhavan Srinivasan
2014-11-27 12:18 ` [RFC PATCH 1/2]powerpc: foundation code to handle CR5 for local_t Madhavan Srinivasan
2014-11-27 16:56 ` Segher Boessenkool
2014-11-28 1:58 ` Benjamin Herrenschmidt
2014-11-28 3:00 ` Madhavan Srinivasan
2014-11-28 15:57 ` Segher Boessenkool
2014-11-28 2:57 ` Madhavan Srinivasan
2014-11-28 16:00 ` Segher Boessenkool
2014-11-28 0:56 ` Benjamin Herrenschmidt
2014-11-28 3:15 ` Madhavan Srinivasan
2014-11-28 3:21 ` Benjamin Herrenschmidt
2014-11-28 10:53 ` David Laight
2014-11-30 9:01 ` Benjamin Herrenschmidt
2014-12-01 21:35 ` Gabriel Paubert
2014-12-03 14:59 ` Madhavan Srinivasan
2014-12-03 17:07 ` Gabriel Paubert
2014-12-02 2:04 ` Scott Wood
2014-12-03 14:49 ` Madhavan Srinivasan
2014-11-27 12:18 ` [RFC PATCH 2/2]powerpc: rewrite local_* to use CR5 flag Madhavan Srinivasan
2014-12-01 18:01 ` Gabriel Paubert
2014-12-03 15:05 ` Madhavan Srinivasan
2014-11-27 14:05 ` [RFC PATCH 0/2] powerpc: CR based local atomic operation implementation David Laight
2014-11-28 8:27 ` Madhavan Srinivasan [this message]
2014-11-28 10:09 ` David Laight
2014-12-01 15:35 ` Madhavan Srinivasan
2014-12-01 15:53 ` David Laight
2014-12-18 4:18 ` Rusty Russell
2014-12-18 9:52 ` David Laight
2014-12-18 10:53 ` Rusty Russell
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=547831DC.6000703@linux.vnet.ibm.com \
--to=maddy@linux.vnet.ibm.com \
--cc=David.Laight@ACULAB.COM \
--cc=anton@samba.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=rusty@rustcorp.com.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.