Cc: Zhang, Yanmin <yanmin_zhang@...>, Andi Kleen <andi@...>, Matthew Wilcox <matthew@...>, LKML <linux-kernel@...>, Alexander Viro <viro@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>
yeah. I thought about that too, the problem i found is this thing in the
old lib/semaphore-sleepers.c code's __down() path:
remove_wait_queue_locked(&sem->wait, &wait);
wake_up_locked(&sem->wait);
spin_unlock_irqrestore(&sem->wait.lock, flags);
tsk->state = TASK_RUNNING;
that mystery wakeup once i understood to be necessary for some weird
ordering reason, but it would probably be hard to justify in the new
code, because it's done unconditionally, regardless of whether there are
sleepers around.
And once we deviate from the old code, we might as well go for the
simplest approach - which also happens to be rather close to the mutex
code's current slowpath - just with counting property added, legacy
semantics and no lockdep coverage.
great! Meanwhile a 100 randconfigs booted fine with that tree so i'd say
the implementation is robust.
i also did a quick re-test of AIM7 because the wakeup logic changed a
bit from what i tested initially (from round-robin to strict FIFO), and
as expected not much changed in the AIM7 results on the quad:
Tasks Jobs/Min JTI Real CPU Jobs/sec/task
2000 55019.9 96 211.6 806.5 0.4585
2000 55116.2 90 211.2 804.7 0.4593
2000 55082.3 82 211.3 805.5 0.4590
this is slightly lower but the test was not fully apples to apples
because this also had some tracing active and other small details. It's
still very close to the v2.6.25 numbers. I suspect some more performance
could be won in this particular workload by getting rid of the BKL
dependency altogether.
Ingo
--
