lkml.org 
[lkml]   [2011]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 0/5] Introduce checks for preemptable code for this_cpu_read/write()
* Steven Rostedt (rostedt@goodmis.org) wrote:
> [ Added Mathieu as I've been discussing this with him on IRC ]
[...]
> My suggestion is to nuke the __this_cpu*() functions and have them
> called this_cpu*(). And change the locations that allow for preemption
> enabled to be called preemptsafe_cpu_*() just like the irqsafe_cpu*()
> are used.
>
> Thoughts?

I fully agreed with this proposal.

this_cpu_*() should be a sane default, which is cases that require
preemption to be disabled. Warning about use without preemption disabled
is important, because most users will _assume_ that they stay on the
same CPU across multiple calls.

preemptsafe_cpu_*() is an optimisation made for those who know that
they don't care about having consistent view of the variables across
multiple operations, e.g. statistics, or deal with this explicitly, like
SLUB. Typical use require either add_return or cmpxchg for validation.

In the past, we used to have something like raw_smp_processor_id()
though, for sites where racy use does not matter. So probably having a
raw_this_cpu_*() that behaves like "this_cpu_*()" proposed here, but
does not check for preemption disabled would also be useful.

Best regards,

Mathieu

--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com


\
 
 \ /
  Last update: 2011-09-20 17:49    [W:0.114 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site