Andi Kleen wrote:
On Saturday 07 January 2006 04:19, Nick Piggin wrote:
Andi Kleen wrote:
On Saturday 07 January 2006 03:52, Nick Piggin wrote:
No. On many load/store architectures there is no good way to do local_t,
so something like ppc32 or ia64 just uses all atomic operations for
well, they're just broken and need to be fixed to not do that.
How?
If anything use the 3x duplicated data setup, not atomic operations.
At a 3x cache footprint cost? (and probably more than 3x for icache, though
I haven't checked) And I think hardware trends are against us. (Also, does
it have race issues with nested interrupts that Andrew noticed?)
Also I bet with some tricks a seqlock like setup could be made to work.
I asked you how before. If you can come up with a way then it indeed
might be a good solution...
I'll try to work something up.
Cool, I'd be interested to see.
The problem I see with seqlock is that it
is only fast in the read path. That path is not the issue here.
The common case - not getting interrupted would be fast.
The problem is that you can never do the final store without risking a
race with an interrupt. Because it is not a read-path.
The closest think I can see to a seqlock would be ll/sc operations, at
which point you're back to atomic ops.
local_t, and ppc64 uses 3 counters per-cpu thus tripling the cache
footprint.
and ppc64 has big caches so this also shouldn't be a problem.
Well it is even less of a problem for them now, by about 1/3.
Performance-wise there is really no benefit for even i386 or x86-64
to move to local_t now either so I don't see what the fuss is about.
Actually P4 doesn't like CLI/STI. For AMD and P-M it's not that much an issue,
but NetBurst really doesn't like it.
Yes, it was worth over a second of real time and ~ 7% total kernel
time on kbuild on a P4.
(git: a74609fafa2e5cc31d558012abaaa55ec9ad9da4)
AMD and PM I didn't test but the improvement might still be noticable,
if much smaller.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
