On Mon, Sep 08, 2014 at 01:20:30PM -0500, Christoph Lameter wrote:
>
> On Thu, 4 Sep 2014, Paul E. McKenney wrote:
>
> > The lglocks use should be of particular interest to you. See above to
> > find the others.
>
> Well the other seem to be in drivers.
OK...
> > Understood, but no hasty
On Mon, Sep 08, 2014 at 01:20:30PM -0500, Christoph Lameter wrote:
On Thu, 4 Sep 2014, Paul E. McKenney wrote:
The lglocks use should be of particular interest to you. See above to
find the others.
Well the other seem to be in drivers.
OK...
Understood, but no hasty changes to
On Thu, 4 Sep 2014, Paul E. McKenney wrote:
> The lglocks use should be of particular interest to you. See above to
> find the others.
Well the other seem to be in drivers.
> Understood, but no hasty changes to that part of RCU.
At our age I think we have learned to be very deliberate and
On Thu, 4 Sep 2014, Paul E. McKenney wrote:
The lglocks use should be of particular interest to you. See above to
find the others.
Well the other seem to be in drivers.
Understood, but no hasty changes to that part of RCU.
At our age I think we have learned to be very deliberate and slow.
On Wed, 3 Sep 2014, Paul E. McKenney wrote:
> As noted earlier, in theory, the atomic operations could be nonatomic,
Well as demonstrated by the patch earlier: The atomic operations are only
used on a the local cpu. There is no synchronization in that sense needed
between processors because
On Thu, 4 Sep 2014, Paul E. McKenney wrote:
> So in short, you don't see the potential for this use case actually
> breaking anything, correct?
In general its a performance impact but depending on how this_cpu_ops may
be implemented in a particular platform there may also be correctness
issues
On Thu, 4 Sep 2014, Paul E. McKenney wrote:
So in short, you don't see the potential for this use case actually
breaking anything, correct?
In general its a performance impact but depending on how this_cpu_ops may
be implemented in a particular platform there may also be correctness
issues
On Wed, 3 Sep 2014, Paul E. McKenney wrote:
As noted earlier, in theory, the atomic operations could be nonatomic,
Well as demonstrated by the patch earlier: The atomic operations are only
used on a the local cpu. There is no synchronization in that sense needed
between processors because
On Thu, Sep 04, 2014 at 01:19:29PM -0500, Christoph Lameter wrote:
> On Thu, 4 Sep 2014, Paul E. McKenney wrote:
>
> > So in short, you don't see the potential for this use case actually
> > breaking anything, correct?
>
> In general its a performance impact but depending on how this_cpu_ops may
On Thu, Sep 04, 2014 at 10:04:17AM -0500, Christoph Lameter wrote:
>
> On Wed, 3 Sep 2014, Paul E. McKenney wrote:
>
> > As noted earlier, in theory, the atomic operations could be nonatomic,
>
> Well as demonstrated by the patch earlier: The atomic operations are only
> used on a the local
On Thu, Sep 04, 2014 at 01:19:29PM -0500, Christoph Lameter wrote:
On Thu, 4 Sep 2014, Paul E. McKenney wrote:
So in short, you don't see the potential for this use case actually
breaking anything, correct?
In general its a performance impact but depending on how this_cpu_ops may
be
On Thu, Sep 04, 2014 at 10:04:17AM -0500, Christoph Lameter wrote:
On Wed, 3 Sep 2014, Paul E. McKenney wrote:
As noted earlier, in theory, the atomic operations could be nonatomic,
Well as demonstrated by the patch earlier: The atomic operations are only
used on a the local cpu. There
On Wed, Sep 03, 2014 at 12:43:15PM -0500, Christoph Lameter wrote:
> On Wed, 3 Sep 2014, Paul E. McKenney wrote:
>
> > > Well, a shared data structure would be cleaner in general but there are
> > > certainly other approaches.
> >
> > Per-CPU variables -are- a shared data structure.
>
> No the
On Wed, 3 Sep 2014, Paul E. McKenney wrote:
> > Well, a shared data structure would be cleaner in general but there are
> > certainly other approaches.
>
> Per-CPU variables -are- a shared data structure.
No the intent is for them to be for the particular cpu and therefore
there is limited
On Wed, Sep 03, 2014 at 10:51:13AM -0500, Christoph Lameter wrote:
> On Wed, 3 Sep 2014, Paul E. McKenney wrote:
>
> > You would prefer that I instead allocated an NR_CPUS-sized array?
>
> Well, a shared data structure would be cleaner in general but there are
> certainly other approaches.
On Wed, 3 Sep 2014, Paul E. McKenney wrote:
> You would prefer that I instead allocated an NR_CPUS-sized array?
Well, a shared data structure would be cleaner in general but there are
certainly other approaches.
But lets focus on the dynticks_idle case we are discussing here rather
than tackle
On Wed, Sep 03, 2014 at 09:10:24AM -0500, Christoph Lameter wrote:
> On Tue, 2 Sep 2014, Paul E. McKenney wrote:
>
> > On Tue, Sep 02, 2014 at 06:22:52PM -0500, Christoph Lameter wrote:
> > > On Tue, 2 Sep 2014, Paul E. McKenney wrote:
> > >
> > > > Yep, these two have been on my "when I am
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
> On Tue, Sep 02, 2014 at 06:22:52PM -0500, Christoph Lameter wrote:
> > On Tue, 2 Sep 2014, Paul E. McKenney wrote:
> >
> > > Yep, these two have been on my "when I am feeling insanely gutsy" list
> > > for quite some time.
> > >
> > > But I have to
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
On Tue, Sep 02, 2014 at 06:22:52PM -0500, Christoph Lameter wrote:
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
Yep, these two have been on my when I am feeling insanely gutsy list
for quite some time.
But I have to ask... On x86, is a
On Wed, Sep 03, 2014 at 09:10:24AM -0500, Christoph Lameter wrote:
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
On Tue, Sep 02, 2014 at 06:22:52PM -0500, Christoph Lameter wrote:
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
Yep, these two have been on my when I am feeling insanely
On Wed, 3 Sep 2014, Paul E. McKenney wrote:
You would prefer that I instead allocated an NR_CPUS-sized array?
Well, a shared data structure would be cleaner in general but there are
certainly other approaches.
But lets focus on the dynticks_idle case we are discussing here rather
than tackle
On Wed, Sep 03, 2014 at 10:51:13AM -0500, Christoph Lameter wrote:
On Wed, 3 Sep 2014, Paul E. McKenney wrote:
You would prefer that I instead allocated an NR_CPUS-sized array?
Well, a shared data structure would be cleaner in general but there are
certainly other approaches.
Per-CPU
On Wed, 3 Sep 2014, Paul E. McKenney wrote:
Well, a shared data structure would be cleaner in general but there are
certainly other approaches.
Per-CPU variables -are- a shared data structure.
No the intent is for them to be for the particular cpu and therefore
there is limited support for
On Wed, Sep 03, 2014 at 12:43:15PM -0500, Christoph Lameter wrote:
On Wed, 3 Sep 2014, Paul E. McKenney wrote:
Well, a shared data structure would be cleaner in general but there are
certainly other approaches.
Per-CPU variables -are- a shared data structure.
No the intent is for
On Tue, Sep 02, 2014 at 06:22:52PM -0500, Christoph Lameter wrote:
> On Tue, 2 Sep 2014, Paul E. McKenney wrote:
>
> > Yep, these two have been on my "when I am feeling insanely gutsy" list
> > for quite some time.
> >
> > But I have to ask... On x86, is a pair of mfence instructions really
> >
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
> Yep, these two have been on my "when I am feeling insanely gutsy" list
> for quite some time.
>
> But I have to ask... On x86, is a pair of mfence instructions really
> cheaper than an atomic increment?
Not sure why you would need an mfence
On Tue, Sep 02, 2014 at 03:47:55PM -0500, Christoph Lameter wrote:
> On Tue, 2 Sep 2014, Paul E. McKenney wrote:
>
> > But yes, in theory, something like this can work if appropriate memory
> > barriers are put in place. In practice, this sort of change needs
> > profound testing on multiple
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
> But yes, in theory, something like this can work if appropriate memory
> barriers are put in place. In practice, this sort of change needs
> profound testing on multiple architectures.
Ok how can we move forward? I just looked further and it seems a
On Tue, Sep 02, 2014 at 03:14:43PM -0500, Christoph Lameter wrote:
>
> Since dynticks_idle is only ever modified by the local cpu we do
> not need to use an atomic there. The weak "atomicity" of this_cpu
> ops is sufficient since there is no other cpu modifying the variable.
>
> [This is a
Since dynticks_idle is only ever modified by the local cpu we do
not need to use an atomic there. The weak "atomicity" of this_cpu
ops is sufficient since there is no other cpu modifying the variable.
[This is a cautious patch that leaves the barriers in place]
Signed-off-by: Christoph Lameter
Since dynticks_idle is only ever modified by the local cpu we do
not need to use an atomic there. The weak atomicity of this_cpu
ops is sufficient since there is no other cpu modifying the variable.
[This is a cautious patch that leaves the barriers in place]
Signed-off-by: Christoph Lameter
On Tue, Sep 02, 2014 at 03:14:43PM -0500, Christoph Lameter wrote:
Since dynticks_idle is only ever modified by the local cpu we do
not need to use an atomic there. The weak atomicity of this_cpu
ops is sufficient since there is no other cpu modifying the variable.
[This is a cautious
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
But yes, in theory, something like this can work if appropriate memory
barriers are put in place. In practice, this sort of change needs
profound testing on multiple architectures.
Ok how can we move forward? I just looked further and it seems a
On Tue, Sep 02, 2014 at 03:47:55PM -0500, Christoph Lameter wrote:
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
But yes, in theory, something like this can work if appropriate memory
barriers are put in place. In practice, this sort of change needs
profound testing on multiple
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
Yep, these two have been on my when I am feeling insanely gutsy list
for quite some time.
But I have to ask... On x86, is a pair of mfence instructions really
cheaper than an atomic increment?
Not sure why you would need an mfence instruction?
On Tue, Sep 02, 2014 at 06:22:52PM -0500, Christoph Lameter wrote:
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
Yep, these two have been on my when I am feeling insanely gutsy list
for quite some time.
But I have to ask... On x86, is a pair of mfence instructions really
cheaper than
36 matches
Mail list logo
