vnlru_proc_wait problem and vnlru_proc MPLock reduction

Venkatesh Srinivas me at endeavour.zapto.org
Fri Dec 17 09:10:24 PST 2010


Hi,

I think vnlru_proc_wait has a bug:
(current)

void
vnlru_proc_wait(void)
{
        if (vnlruproc_sig == 0) {
                vnlruproc_sig = 1;      /* avoid unnecessary wakeups */
                wakeup(vnlruthread);
        }
        tsleep(&vnlruproc_sig, 0, "vlruwk", hz);
}

vnlru_proc() {
. ..
               if (numvnodes - freevnodes <= desiredvnodes * 9 / 10) {
                        vnlruproc_sig = 0;
                        wakeup(&vnlruproc_sig);
                        tsleep(vnlruthread, 0, "vlruwt", hz);
                        continue;
                }
. ..
}

If vnlru_proc_wait wakes the vnlru thread, it finds / frees, w/e
sufficient vnode space, then sends a wakeup on the vnlruproc_sig flag,
and then we hit tsleep(), we will wait for hz to expire even if we
could have gone ahead with the path calling it (allocating things).

2)
All of vnlru_proc is under the mplock; but it looks like we already
read/write to/from the numvnodes/etc counters w/o it. We can probably
move the get_mplock() to just before the cache_hysteresis() call
(freesomevnodes() claims to be mpsafe...).

3)
Why is vnlru_proc in a critical section?

Thanks,
-- vs





More information about the Kernel mailing list