Messages in this thread | | | Date | Thu, 9 Sep 2004 08:41:23 -0400 (EDT) | From | Zwane Mwaikambo <> | Subject | Re: [PATCH][5/8] Arch agnostic completely out of line locks / ppc64 |
| |
Hello Paul,
On Thu, 9 Sep 2004, Paul Mackerras wrote:
> Just got a chance to look at the new out-of-line spinlock stuff > (better late than never :). I see a couple of problems there. First, > we now go two levels deep on SMP && PREEMPT: spin_lock is _spin_lock, > which is out of line in kernel/sched.c. That calls > __preempt_spin_lock, which is out of line in kernel/sched.c, and isn't > in the .text.lock section. So if we get a timer interrupt in there, > we won't attribute the profile tick to the original caller.
I think that bit is actually intentional since __preempt_spin_lock is also marked __sched so that it'll get charged as a scheduling function.
> The second problem is that __preempt_spin_lock doesn't do the yield to > the hypervisor which we need to do on shared processor systems. This > is actually a long-standing problem, not one you have just introduced, > but I have only just noticed it. I can't make cpu_relax do the yield > because the yield is a directed yield to a specific other virtual cpu > (it says "give the rest of my timeslice to that guy over there") and I > need the value in the lock variable in order to know who is holding > the lock.
I think cpu_relax() (or some other primitive) should actually take a parameter, this will allow for us to use monitor/mwait on i386 too so that in cases where we're spinning waiting on memory modify we could do something akin to the following;
while (spin_is_locked(lock)) cpu_relax(lock);
Although there are wakeup latencies when using monitor/mwait for such, some cases such as above should be ok (although there are implementation details such as the cost of a monitor operation on things like spin unlock paths). I believe such an API modification would be beneficiel for you too. What do others think?
Thanks, Zwane - 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/
| |