On Thu, 17 Jul 2014, Pranith Kumar wrote:
> > then we have on x86 a increment operation with locked semantics racing
> > with an unlocked one on the same cacheline.
> OK, I will add this as a warning in the documentation. Thanks!
Note that I have not been able to get beyond a bad feeling. Looked
On Thu, 17 Jul 2014, Pranith Kumar wrote:
then we have on x86 a increment operation with locked semantics racing
with an unlocked one on the same cacheline.
OK, I will add this as a warning in the documentation. Thanks!
Note that I have not been able to get beyond a bad feeling. Looked up
On 07/17/2014 11:19 AM, Christoph Lameter wrote:
> Regarding atomic_t in per cpu areas: I am uncomfortable especially
> because both locked and unlocked RMW write operations could be acting on
> values in the same cacheline. I am concerned that the unlocked operation
> could have an unpredictable
On 07/17/2014 11:26 AM, Christoph Lameter wrote:
> On Thu, 17 Jul 2014, Pranith Kumar wrote:
>
>> I can mention that IPI is preferable. What is that you don't want mentioned?
>> atomic_t?
>
> Definitely not as an example. atomic_t in per cpu areas is self
> contradicting. The per cpu area is
On Thu, 17 Jul 2014, Pranith Kumar wrote:
> I can mention that IPI is preferable. What is that you don't want mentioned?
> atomic_t?
Definitely not as an example. atomic_t in per cpu areas is self
contradicting. The per cpu area is exclusively for that processor whereas
an atomic_t is supposed
Regarding atomic_t in per cpu areas: I am uncomfortable especially
because both locked and unlocked RMW write operations could be acting on
values in the same cacheline. I am concerned that the unlocked operation
could have an unpredictable result.
f.e. the following per cpu data structure
On 07/17/2014 10:55 AM, Christoph Lameter wrote:
> On Thu, 17 Jul 2014, Pranith Kumar wrote:
>
>>> The RCU code has u... some issues with percpu usage and should
>>> not be taken as a good example. If you look at the RCU code it looks
>>> horrible with numerous barriers around remote
On Thu, 17 Jul 2014, Pranith Kumar wrote:
> > The RCU code has u... some issues with percpu usage and should
> > not be taken as a good example. If you look at the RCU code it looks
> > horrible with numerous barriers around remote percpu read/wrirte
> > accesses and one wonders if that
On 07/17/2014 10:39 AM, Christoph Lameter wrote:
> On Thu, 17 Jul 2014, Pranith Kumar wrote:
>
>>> The use of atomic_t implies a remote write operation to a percpu area.
>>>
>>> atomic_t needs to be avoided. If data needs to be modified from multiple
>>> cpus then it usually does not belong into
On Thu, 17 Jul 2014, Pranith Kumar wrote:
> > The use of atomic_t implies a remote write operation to a percpu area.
> >
> > atomic_t needs to be avoided. If data needs to be modified from multiple
> > cpus then it usually does not belong into a percpu area.
> >
>
> Yes, I think I made it pretty
Note my earlier comments. And there is no such email address as
o...@gentwo.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
On Wed, 16 Jul 2014, Pranith Kumar wrote:
> +You can also do the following to convert the datap offset to an address
> +
> + struct data *p = this_cpu_ptr();
> +
> +but, passing of pointers calculated via this_cpu_ptr to other cpus is
> +unusual and should be avoided.
> +
> +Such remote
On Wed, 16 Jul 2014, Pranith Kumar wrote:
+You can also do the following to convert the datap offset to an address
+
+ struct data *p = this_cpu_ptr(datap);
+
+but, passing of pointers calculated via this_cpu_ptr to other cpus is
+unusual and should be avoided.
+
+Such remote accesses
Note my earlier comments. And there is no such email address as
o...@gentwo.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
On Thu, 17 Jul 2014, Pranith Kumar wrote:
The use of atomic_t implies a remote write operation to a percpu area.
atomic_t needs to be avoided. If data needs to be modified from multiple
cpus then it usually does not belong into a percpu area.
Yes, I think I made it pretty clear that
On 07/17/2014 10:39 AM, Christoph Lameter wrote:
On Thu, 17 Jul 2014, Pranith Kumar wrote:
The use of atomic_t implies a remote write operation to a percpu area.
atomic_t needs to be avoided. If data needs to be modified from multiple
cpus then it usually does not belong into a percpu area.
On Thu, 17 Jul 2014, Pranith Kumar wrote:
The RCU code has u... some issues with percpu usage and should
not be taken as a good example. If you look at the RCU code it looks
horrible with numerous barriers around remote percpu read/wrirte
accesses and one wonders if that code is
On 07/17/2014 10:55 AM, Christoph Lameter wrote:
On Thu, 17 Jul 2014, Pranith Kumar wrote:
The RCU code has u... some issues with percpu usage and should
not be taken as a good example. If you look at the RCU code it looks
horrible with numerous barriers around remote percpu
Regarding atomic_t in per cpu areas: I am uncomfortable especially
because both locked and unlocked RMW write operations could be acting on
values in the same cacheline. I am concerned that the unlocked operation
could have an unpredictable result.
f.e. the following per cpu data structure
On Thu, 17 Jul 2014, Pranith Kumar wrote:
I can mention that IPI is preferable. What is that you don't want mentioned?
atomic_t?
Definitely not as an example. atomic_t in per cpu areas is self
contradicting. The per cpu area is exclusively for that processor whereas
an atomic_t is supposed to
On 07/17/2014 11:26 AM, Christoph Lameter wrote:
On Thu, 17 Jul 2014, Pranith Kumar wrote:
I can mention that IPI is preferable. What is that you don't want mentioned?
atomic_t?
Definitely not as an example. atomic_t in per cpu areas is self
contradicting. The per cpu area is exclusively
On 07/17/2014 11:19 AM, Christoph Lameter wrote:
Regarding atomic_t in per cpu areas: I am uncomfortable especially
because both locked and unlocked RMW write operations could be acting on
values in the same cacheline. I am concerned that the unlocked operation
could have an unpredictable
Add more details from a recent kernel newbies mailing list discussion here:
http://www.spinics.net/lists/newbies/msg52747.html
Also list the operations available and add details about safe accesses.
v2:
* updated with comments from Christoph Lameter
Signed-off-by: Pranith Kumar
CC: Christoph
Add more details from a recent kernel newbies mailing list discussion here:
http://www.spinics.net/lists/newbies/msg52747.html
Also list the operations available and add details about safe accesses.
v2:
* updated with comments from Christoph Lameter
Signed-off-by: Pranith Kumar
24 matches
Mail list logo
