On 2016年06月04日 05:35, Peter Zijlstra wrote:
On Fri, Jun 03, 2016 at 05:20:10PM -0400, Waiman Long wrote:
On 06/03/2016 05:48 AM, Pan Xinhui wrote:
queued_spin_lock_slowpath should not worry about interrupt change
node->count by accident because ->count is inc and dec when we
enter/leave queued_spin_lock_slowpath.
So this_cpu_dec() does some no point things here, lets use this_cpu_ptr
for a small optimization.
Signed-off-by: Pan Xinhui<[email protected]>
---
kernel/locking/qspinlock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
index 99f31e4..2b4daac 100644
--- a/kernel/locking/qspinlock.c
+++ b/kernel/locking/qspinlock.c
@@ -492,7 +492,7 @@ release:
/*
* release the node
*/
- this_cpu_dec(mcs_nodes[0].count);
+ this_cpu_ptr(&mcs_nodes[0])->count--;
}
EXPORT_SYMBOL(queued_spin_lock_slowpath);
Is this going to generate better code for PPC? For x86, I think it will
cause more instruction to be issued.
yes, ppc will do some check when restore irq flags. it's really heavy.
and yes, such change cause more instructions to be issued.
there is a RELOC_HIDE macro in this_cpu_ptr and gcc can't do optimization.
How about ICC. I once used ICC when I was in intel but i forgot the result.
It does; I think he wants __this_cpu_dec() instead, but the Changelog
needs improvement to explain why that is ok.
oh, great. __this_cpu_dec() is fine. thanks
no any irq flags save/restore again. :)
thanks
xinhui
