On Tue, 3 Sep 2013, Steven Rostedt wrote:
> Right, that's why there's a raw_smp_processor_id() and
> __raw_get_cpu_var(). Those two are the ones without checks, and they
> are called by the non "raw" versions after the check is done.
>
> Really, what's so damn hard about this?
Well you tried it b
On Tue, 3 Sep 2013 16:45:45 +0200
Frederic Weisbecker wrote:
> 2013/9/3 Christoph Lameter :
> > On Thu, 29 Aug 2013, Steven Rostedt wrote:
> >
> >> How many places use the this_cpu_*() without preemption disabled? I
> >> wouldn't think there's many. I never complained about another variant,
> >>
2013/9/3 Christoph Lameter :
> On Thu, 29 Aug 2013, Steven Rostedt wrote:
>
>> How many places use the this_cpu_*() without preemption disabled? I
>> wouldn't think there's many. I never complained about another variant,
>> so you need to ask those that have. The tough question for me is what
>> th
On Thu, 29 Aug 2013, Steven Rostedt wrote:
> How many places use the this_cpu_*() without preemption disabled? I
> wouldn't think there's many. I never complained about another variant,
> so you need to ask those that have. The tough question for me is what
> that variant name should be ;-)
Tried
* Christoph Lameter wrote:
> On Thu, 29 Aug 2013, Steven Rostedt wrote:
>
> > On Thu, Aug 29, 2013 at 04:57:43PM +, Christoph Lameter wrote:
> > >
> > > We could add a this_cpu variant that would be used in the cases we do
> > > not want preemption checks? There should not be too many b
On Thu, 29 Aug 2013 18:15:43 +
Christoph Lameter wrote:
> On Thu, 29 Aug 2013, Steven Rostedt wrote:
>
> Its not really an atomic operation in the classic sense.
It doesn't need to be atomic, it could mean it is used within atomic
locations. Basically, "can't be interrupted here". I just sa
On Thu, 29 Aug 2013, Steven Rostedt wrote:
> On Thu, Aug 29, 2013 at 04:57:43PM +, Christoph Lameter wrote:
> >
> > We could add a this_cpu variant that would be used in the cases we do
> > not want preemption checks? There should not be too many but it will
> > mean a whole lot of new def
On Thu, Aug 29, 2013 at 04:57:43PM +, Christoph Lameter wrote:
>
> We could add a this_cpu variant that would be used in the cases we do
> not want preemption checks? There should not be too many but it will
> mean a whole lot of new definitions in percpu.h.
Let's get away from underscore
On Thu, 29 Aug 2013, Ingo Molnar wrote:
>
> >
> >
> > Seriously first fix the debug and validation bits of the *this_cpu*
> > stuff.
>
> Note that most of the other 'gcv' patches have these problems as well, so
> it's a NAK from me as well for most of the other patches as well ...
Note that this
* Peter Zijlstra wrote:
> On Wed, Aug 28, 2013 at 07:48:14PM +, Christoph Lameter wrote:
> > Transformations done to __get_cpu_var()
> >
> >
> > 1. Determine the address of the percpu instance of the current processor.
> >
> > DEFINE_PER_CPU(int, y);
> > int *x = &__get_cpu_var(y)
On Wed, Aug 28, 2013 at 07:48:14PM +, Christoph Lameter wrote:
> Transformations done to __get_cpu_var()
>
>
> 1. Determine the address of the percpu instance of the current processor.
>
> DEFINE_PER_CPU(int, y);
> int *x = &__get_cpu_var(y);
>
> Converts to
>
> int *
__get_cpu_var() is used for multiple purposes in the kernel source. One of them
is
address calculation via the form &__get_cpu_var(x). This calculates the address
for
the instance of the percpu variable of the current processor based on an offset.
Other use cases are for storing and retrieving d
12 matches
Mail list logo
