lkml.org 
[lkml]   [2004]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ANNOUNCE] Linux 2.6 Real Time Kernel

    * Sven Dietrich <sdietrich@mvista.com> wrote:

    > IMO the number of raw_spinlocks should be lower, I said teens before.
    >
    > Theoretically, it should only need to be around hardware registers and
    > some memory maps and cache code, plus interrupt controller and other
    > SMP-contended hardware.

    yeah, fully agreed. Right now the 90 locks i have means roughly 20% of
    all locking still happens as raw spinlocks.

    But, there is a 'correctness' _minimum_ set of spinlocks that _must_ be
    raw spinlocks - this i tried to map in the -T4 patch. The patch does run
    on SMP systems for example. (it was developed as an SMP kernel - in fact
    i never compiled it as UP :-|.) If code has per-CPU or preemption
    assumptions then there is no choice but to make it a raw spinlock, until
    those assumptions are fixed.

    > There are some concurrency issues in kernel threads, and I think there
    > is a lot of work here. The abstraction for LOCK_OPS is a good
    > alternative, but like the spin_undefs, its difficult to tell in the
    > code whether you are dealing with a mutex or a spinlock.

    what do you mean by 'it's difficult to tell'? In -T4 you do the choice
    of type in the data structure and the API adapts automatically. If the
    type is raw_spinlock_t then a spin_lock() is turned into a
    _raw_spin_lock(). If the type is spinlock_t then the spin_lock() is
    redirected to mutex_lock(). It's all transparently done and always
    correct.

    > There are a whole lot of caveats and race conditions that have not yet
    > been unearthed by the brief LKML testing. [...]

    actually, have you tried your patchset on an SMP box? As far as i can
    see the locking in it ignores SMP issues _completely_, which makes the
    choice of locks much less useful.

    Ingo
    -
    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:06    [W:0.037 / U:0.136 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site