RE: [git pull] ia64 changes

Luck, Tony
2009-09-29T17:53:34Z

> That said, the 8% slowdown sounds like a real problem. Maybe Tony's
> original version (perhaps with a "ld.bias" to get the initial load to try
> to get exclusive ownership) is worth the size expansion

The 8%/16% numbers are absolute worst case values. They are based on
the time to acquire and release a lock in the case where the lock is
resident in the L1 cache of the cpu running the code. So I'm looking
at 24 cycles for the old xchg-based version. 26 cycles for 8-byte ticket
locks and 28-cycles for 4-byte ticket locks.

The real world is likely to be much kinder. If the lock is being
acquired by different cpus, then we'll have to go to memory (or remote
cache, which is just as bad) to get the lock. Then the 2-4 extra cycles
will be a much tinier percentage of the total. Even if the lock is being
mostly used by a single cpu with only occasional remote access, it still
isn't likely to live in the L1 cache ... so we'd see another 14 cycles if
we had to pull it back into L1 from L3.

Any feel for how much memory this is going to cost? Although there is
a spinlock inside "struct page" it is buried in a union with a larger
structure. So changing from 4 to 8 bytes makes no difference to the
total size of the structure. For statically declared locks the
difference reported by "size vmlinux" is laughably small (~4KB!)

What will be the big areas of growth? dentry? inode? Something off
in networking?

-Tony