On Tuesday 02 December 2014 07:34 AM, Scott Wood wrote:
On Thu, 2014-11-27 at 17:48 +0530, Madhavan Srinivasan wrote:
- I really appreciate feedback on the patchset.
- Kindly comment if I should try with any other benchmark or
workload to check the numbers.
- Also, kindly recommand any
On Tuesday 02 December 2014 03:05 AM, Gabriel Paubert wrote:
On Thu, Nov 27, 2014 at 05:48:40PM +0530, Madhavan Srinivasan wrote:
This patch create the infrastructure to handle the CR based
local_* atomic operations. Local atomic operations are fast
and highly reentrant per CPU counters.
On Wed, Dec 03, 2014 at 08:29:37PM +0530, Madhavan Srinivasan wrote:
On Tuesday 02 December 2014 03:05 AM, Gabriel Paubert wrote:
On Thu, Nov 27, 2014 at 05:48:40PM +0530, Madhavan Srinivasan wrote:
diff --git a/arch/powerpc/include/asm/exception-64s.h
On Thu, Nov 27, 2014 at 05:48:40PM +0530, Madhavan Srinivasan wrote:
This patch 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
On Thu, 2014-11-27 at 17:48 +0530, Madhavan Srinivasan wrote:
- I really appreciate feedback on the patchset.
- Kindly comment if I should try with any other benchmark or
workload to check the numbers.
- Also, kindly recommand any know stress test for CR
Makefile
On Fri, 2014-11-28 at 10:53 +, David Laight wrote:
From: Benjamin Herrenschmidt
On Fri, 2014-11-28 at 08:45 +0530, Madhavan Srinivasan wrote:
Can't we just unconditionally clear at as long as we do that after we've
saved it ? In that case, it's just a matter for the fixup code to
From: Benjamin Herrenschmidt
On Fri, 2014-11-28 at 08:45 +0530, Madhavan Srinivasan wrote:
Can't we just unconditionally clear at as long as we do that after we've
saved it ? In that case, it's just a matter for the fixup code to check
the saved version rather than the actual CR..
I
On Fri, Nov 28, 2014 at 12:58:55PM +1100, Benjamin Herrenschmidt wrote:
Have you tested this with (upcoming) GCC 5.0? GCC now uses CR5,
and it likes to use it very much, it might be more convenient to
use e.g. CR1 (which is allocated almost last, only before CR0).
We use CR1 all over the
On Fri, Nov 28, 2014 at 08:27:22AM +0530, Madhavan Srinivasan wrote:
Have you tested this with (upcoming) GCC 5.0? GCC now uses CR5,
and it likes to use it very much, it might be more convenient to
use e.g. CR1 (which is allocated almost last, only before CR0).
No. I did not try it with
This patch 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
On Thu, Nov 27, 2014 at 05:48:40PM +0530, Madhavan Srinivasan wrote:
Here is the design of this 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
On Thu, 2014-11-27 at 17:48 +0530, Madhavan Srinivasan wrote:
This patch 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
On Thu, 2014-11-27 at 10:56 -0600, Segher Boessenkool wrote:
On Thu, Nov 27, 2014 at 05:48:40PM +0530, Madhavan Srinivasan wrote:
Here is the design of this patch. Since local_* operations
are only need to be atomic to interrupts (IIUC), patch uses
one of the Condition Register (CR)
On Thursday 27 November 2014 10:26 PM, Segher Boessenkool wrote:
On Thu, Nov 27, 2014 at 05:48:40PM +0530, Madhavan Srinivasan wrote:
Here is the design of this patch. Since local_* operations
are only need to be atomic to interrupts (IIUC), patch uses
one of the Condition Register (CR)
On Friday 28 November 2014 07:28 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-11-27 at 10:56 -0600, Segher Boessenkool wrote:
On Thu, Nov 27, 2014 at 05:48:40PM +0530, Madhavan Srinivasan wrote:
Here is the design of this patch. Since local_* operations
are only need to be atomic to
On Friday 28 November 2014 06:26 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-11-27 at 17:48 +0530, Madhavan Srinivasan wrote:
This patch create the infrastructure to handle the CR based
local_* atomic operations. Local atomic operations are fast
and highly reentrant per CPU counters.
On Fri, 2014-11-28 at 08:45 +0530, Madhavan Srinivasan wrote:
Can't we just unconditionally clear at as long as we do that after we've
saved it ? In that case, it's just a matter for the fixup code to check
the saved version rather than the actual CR..
I use CR bit setting in the
17 matches
Mail list logo
