Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9

[Nikita Danilov]

Ingo Molnar writes:
 > 
 > * Nikita Danilov <nikita@xxxxxxxxxxxxx> wrote:
 > 
 > >  > condition variables are fine if you 1) already know them from userspace
 > >  > and 2) want to use a single locking abstraction for everything. It is
 > >  > thus also a kitchen-sink primitive that is inevitably slow and complex.
 > >  > I still have to see a locking problem where condvars are the
 > >  > cleanest/simplest answer, and i've yet to see a locking problem where
 > >  > condvars are not the slowest answer ;)
 > > 
 > > A kernel daemon that waits for some work to do is an example.
 > 
 > what type of work - could you be a bit more specific?

Take a loop in fs/cifs/cifsfs.c:cifs_oplock_thread() (I won't copy it
here to avoid you all going blind). It can be recoded as

    while(1) {
        spin_lock(&GlobalMid_Lock);
        while (list_empty(&GlobalOplock_Q)) {
             if (kcond_timedwait(&SomeCIFSCVAR, &GlobalMid_Lock, HZ) == -EINTR) {
                     spin_unlock(&GlobalMid_Lock);
                     complete_and_exit(&cifs_oplock_exited, 0);
             }
        }
        oplock_item = list_entry(GlobalOplock_Q.next, struct oplock_q_entry, qhead);
        /* do stuff with oplock_item ... */
        spin_unlock(&GlobalMid_Lock);
        ....
    }

Point is that this is very stylistic usage---easily recognizable.

 > 
 > 	Ingo

Nikita.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/