Hi Christoph,
Thank you for answering.
On Thu, Jul 10, 2014 at 4:25 PM, Christoph Lameter <cl@xxxxxxxxxx> wrote:
> On Thu, 10 Jul 2014, Pranith Kumar wrote:
>
>> Hello,
>>
>> Let us say we have a per-cpu data structure as follows:
>>
>> struct data {
>> atomic_t val;
>> };
>>
>> Since this is a per-cpu data structure, do I need to have 'val' as
>> atomic? Or can I just use a normal 'int' for val?
>
> Per cpu data structures are for the use of one cpu exclusively. If you use
> the variable as intended then there is no atomic_t required. If you want
> to update the percpu variable from other processors then atomic_t is
> required. But then this is not a proper percpu variable anymroe.
>
That also makes using barriers while updating such variables
meaningless I guess? like
smp_mb();
val++;
smp_mb();
since val here is supposed to be per-cpu.
>
>> > Also are the following the same? If yes, which is preferable? >
>> DEFINE_PER_CPU(struct data, datap);
>
> datap is now a fixed offset into the percpu area. The processor can encode
> a load using a segment prefix and the fixed offset if the this_cpu
> operations are being used for accesses.
>
>
>> struct data __percpu *p = &datap;
>
> This wont work without the definition above and will assign the offset of
> datap in the percpu area to p. p can be used with this_cpu operations but
> is not a generally usable pointer. Its an offset into the per cpu area.
>
>> struct data *p = this_cpu_ptr(&datap);
>
> This converts the offset into an address that can be generally used as
> a pointer (but no longer with this_cpu operations).
>
So we can pass around this pointer to other cpus but not the previous
__percpu pointer?
I think adding this information to the documentation would be a great
idea. Especially the "__percpu" annotation. Is it ok if I try?
--
Pranith
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
