lkml.org 
[lkml]   [2004]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectmore (insane) jiffies ranting
    Continuing my rant...

    On Sat, Jun 26, 2004 at 03:48:34PM -0700, Linus Torvalds wrote:

    > But for most data structures, the way to control access is either
    > with proper locking (at which point they aren't volatile any more)
    > or through proper accessor functions (ie "jiffies_64" should
    > generally only be accessed with something that understands about
    > low/high word and update ordering and re-testing).

    I don't entirely buy this. Right now x86 code just assumes 32-bit
    loads are atomic and does them blindly in lots of places (ie. every
    user of jiffies just about).

    Without the volatile it seems entirely reasonable gcc will produce
    correct, but wrong code here so I would argue 'volatile' is a property
    of the data in this case.

    > I repeat: it is the _code_ that knows about volatile rules, not the
    > data structure.

    Except as I mentioned we have exceptions to this right now.

    As far as I can tell jiffies is a mess (I'm talking mostly ia32 here):

    jiffies_64 is protected by xtime_lock, this is a seqlock_t which
    is IMO overly complicated and unnecessary, and this lock is shared
    for xtime as well

    jiffies_64 could be done locklessly as far as I can tell anyhow.

    jiffies is linker-magic to jiffies_64 and works because a
    little-endian load at the same address gives you the 32 lower bits.
    I'm not opposed to this, but a comment wouldn't kill anyone.

    we also have wall_jiffies which is 32-bit (unsigned long, ia32) and
    is used get the gettimeofday code to detect lost ticks, having
    this as well as jiffies_64 seems overkill

    we do xtime updates w/o a lock on most platforms

    Perhaps I misunderstand the code right now, the need for the
    complexity and what-not --- but I don't like it.

    It's either because it's too complicated or it's not-clear what is
    going on, I don't know which one matches reality most closely,
    probably the latter.

    I know there are NTP implications of this this code but it feels more
    like "it happens to work, please don't touch it" rather than anything
    clean and well designed. I'm pretty sure there are some tricky corner
    cases and subtle interactions to worry about, especially when we look
    at leap-seconds.

    Maybe having all this code moved into a single place would help, I'm
    not sure, with platform-provided abstraction as required so older
    platforms which can't do atomic 64-bit updates will still behave
    sanely.

    To be quite honest I'd like to see jiffies die and xtime become a
    per-cpu thing (if that can be made to work reliably, I have some
    concerns), or at least have this option on a platform by platform
    basis.



    --cw
    -
    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: 2005-03-22 14:04    [W:0.021 / U:127.440 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site