lkml.org 
[lkml]   [2008]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH [RT] 07/14] adaptive real-time lock support
    Hi!

    > @@ -192,6 +192,26 @@ config RCU_TRACE
    > Say Y/M here if you want to enable RCU tracing in-kernel/module.
    > Say N if you are unsure.
    >
    > +config ADAPTIVE_RTLOCK
    > + bool "Adaptive real-time locks"
    > + default y

    tabs vs. spaces.

    > + If unsure, say Y

    Missing dot?

    > @@ -7,6 +7,7 @@
    > * Copyright (C) 2005-2006 Timesys Corp., Thomas Gleixner <tglx@timesys.com>
    > * Copyright (C) 2005 Kihon Technologies Inc., Steven Rostedt
    > * Copyright (C) 2006 Esben Nielsen
    > + * Copyright (C) 2008 Novell, Inc.

    It would be nice to list some names, too.

    > --- /dev/null
    > +++ b/kernel/rtmutex_adaptive.h
    > @@ -0,0 +1,134 @@
    > +/*
    > + * Adaptive RT lock support
    > + *
    > + * There are pros and cons when deciding between the two basic forms of
    > + * locking primitives (spinning vs sleeping). Without going into great
    > + * detail on either one, we note that spinlocks have the advantage of
    > + * lower overhead for short hold locks. However, they also have a
    > + * con in that they create indeterminate latencies since preemption
    > + * must traditionally be disabled while the lock is held (to prevent deadlock).
    > + *
    > + * We want to avoid non-deterministic critical sections in -rt. Therefore,
    > + * when realtime is enabled, most contexts are converted to threads, and
    > + * likewise most spinlock_ts are converted to sleepable rt-mutex derived
    > + * locks. This allows the holder of the lock to remain fully preemptible,
    > + * thus reducing a major source of latencies in the kernel.
    > + *
    > + * However, converting what was once a true spinlock into a sleeping lock
    > + * may also decrease performance since the locks will now sleep under
    > + * contention. Since the fundamental lock used to be a spinlock, it is
    > + * highly likely that it was used in a short-hold path and that release
    > + * is imminent. Therefore sleeping only serves to cause context-thrashing.
    > + *
    > + * Adaptive RT locks use a hybrid approach to solve the problem. They
    > + * spin when possible, and sleep when necessary (to avoid deadlock, etc).
    > + * This significantly improves many areas of the performance of the -rt
    > + * kernel.
    > + *
    > + * Copyright (C) 2008 Novell, Inc.,
    > + * Sven Dietrich, Peter Morreale, and Gregory Haskins

    GPL?

    > +/*
    > + * Adaptive-rtlocks will busywait when possible, and sleep only if
    > + * necessary. Note that the busyloop looks racy, and it is....but we do
    > + * not care. If we lose any races it simply means that we spin one more
    > + * time before seeing that we need to break-out on the next iteration.
    > + *
    > + * We realize this is a relatively large function to inline, but note that
    > + * it is only instantiated 1 or 2 times max, and it makes a measurable
    > + * performance different to avoid the call.
    > + *
    > + * Returns 1 if we should sleep
    > + *
    > + */

    Kerneldoc?

    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


    \
     
     \ /
      Last update: 2008-02-22 20:25    [W:4.265 / U:0.592 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site