lkml.org 
[lkml]   [2007]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/24] make atomic_read() behave consistently across all architectures
    Satyam Sharma wrote:

    >
    >On Fri, 17 Aug 2007, Nick Piggin wrote:
    >
    >
    >>Because they should be thinking about them in terms of barriers, over
    >>which the compiler / CPU is not to reorder accesses or cache memory
    >>operations, rather than "special" "volatile" accesses.
    >>
    >
    >This is obviously just a taste thing. Whether to have that forget(x)
    >barrier as something author should explicitly sprinkle appropriately
    >in appropriate places in the code by himself or use a primitive that
    >includes it itself.
    >

    That's not obviously just taste to me. Not when the primitive has many
    (perhaps, the majority) of uses that do not require said barriers. And
    this is not solely about the code generation (which, as Paul says, is
    relatively minor even on x86). I prefer people to think explicitly
    about barriers in their lockless code.


    >I'm not saying "taste matters aren't important" (they are), but I'm really
    >skeptical if most folks would find the former tasteful.
    >

    So I /do/ have better taste than most folks? Thanks! :-)


    >>>And by the way, the point is *also* about the fact that cpu_relax(), as
    >>>of today, implies a full memory clobber, which is not what a lot of such
    >>>loops want. (due to stuff mentioned elsewhere, summarized in that summary)
    >>>
    >>That's not the point,
    >>
    >
    >That's definitely the point, why not. This is why "barrier()", being
    >heavy-handed, is not the best option.
    >

    That is _not_ the point (of why a volatile atomic_read is good) because
    there
    has already been an alternative posted that better conforms with Linux
    barrier
    API and is much more widely useful and more usable. If you are so
    worried about
    barrier() being too heavyweight, then you're off to a poor start by
    wanting to
    add a few K of kernel text by making atomic_read volatile.


    >>because as I also mentioned, the logical extention
    >>to Linux's barrier API to handle this is the order(x) macro. Again, not
    >>special volatile accessors.
    >>
    >
    >Sure, that forget(x) macro _is_ proposed to be made part of the generic
    >API. Doesn't explain why not to define/use primitives that has volatility
    >semantics in itself, though (taste matters apart).
    >

    If you follow the discussion.... You were thinking of a reason why the
    semantics *should* be changed or added, and I was rebutting your argument
    that it must be used when a full barrier() is too heavy (ie. by pointing
    out that order() has superior semantics anyway).

    Why do I keep repeating the same things? I'll not continue bloating this
    thread until a new valid point comes up...
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-08-17 14:57    [W:4.147 / U:0.416 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site