[lkml]   [2008]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: local_add_return
    * Rusty Russell ( wrote:
    > On Friday 19 December 2008 14:05:14 Mathieu Desnoyers wrote:
    > > * Rusty Russell ( wrote:
    > > But can we turn what you call "nmi_safe_t" into "local_atomic_t" then ?
    > > Because we have to specify that this type must only be used as part of
    > > per-cpu data with preemption disabled, and we also specify that it is
    > > atomic.
    > >
    > > Plus, nmi_safe_t does not make much sense on architectures without NMIs,
    > > where we sometimes disable interrupts to make the modification "atomic"
    > > wrt all other interrupts that can happen.
    > But those archs can use local_t. I don't like either name local_t nor
    > atomic_local_t, but renaming sucks too.
    > OK, how about a different approach? Since there's really only one case
    > where we need this local_t property outside arch-specific code, how about
    > we define ARCH_LOCAL_T_TRACE_SAFE for x86?
    > Then some trace-specific typedef like "trace_counter_t" which goes to local_t
    > or atomic_(long?)_t?
    > Should be a simple patch and pretty clear.

    Hrm, is it me or linking a basic type definition to a single user seems
    like the wrong approach ?

    The idea behind declaring new types is, to me, that they should describe
    as generally as possible what they provide and what they are. If we
    think of the future, where we might want to use such local atomic types
    for other purposes than tracing, I think we will end up regretting such
    specific naming scheme. I don't think the argument "because the type has
    only one arch-independent user" holds, because the idea behind new types
    is that they _will_ be used by others eventually. For instance, we've
    done some work on moving the slub allocator to such local atomic
    operations last year, and it gave very good results on architectures
    where disabling interrupt is costly (threefold acceleration of the

    In your trace_counter_t proposal, you don't take into account that (what
    I call) local_atomic_long_t is a _new_ primitive, which cannot be
    implemented by a trivalue and differs from atomic_long_t, on more
    architectures than x86. On mips and powerpc, at least, it can be
    implemented as an atomic operation without the memory barriers, which
    improves performances a lot.

    I think the following scheme would be pretty simple and yet not tied to
    any specific user :

    - Fast per-cpu counter, not necessarily atomic.
    Implements long trivalues, or uses local_atomic_long_t.
    - Fast per-cpu atomic counter.
    Implements per-cpu atomic counters or uses atomic_long_t.
    - Global atomic counter.
    Implements globally synchronized atomic operations.

    We could do the same with "int" type for :

    If we need smaller counters.


    > Thanks,
    > Rusty.

    Mathieu Desnoyers
    OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68

     \ /
      Last update: 2008-12-19 18:09    [W:0.025 / U:157.892 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site