Linus Torvalds writes: (Summary) wrote:
Oh, see that's the difference.
You're running in a non-root cgroup, I think.
You're running in a non-root cgroup, I think.
That also means that your scheduler overhead has way more spinlocks, and in particular, you have that
and in particular, you have that
raw_spinlock_t *cpu_lock = per_cpu_ptr(&cgroup_rstat_cpu_lock, cpu); That's what the AIX docs imply, at least.
That's what the AIX docs imply, at least.
In particular, I find:
In particular, I find:
"isync is not a memory barrier instruction, but the load-compare-conditional branch-isync sequence can provide this ordering property"
ordering property"
so why are you doing "sync/lwsync", when it sounds like "isync/lwsync" (for lock/unlock) is the right thing and would already give memory barrier semantics?
barrier semantics?
Linus
[...]
7.81% context_switch [kernel.kallsyms] [k] cgroup_rstat_updated Oh, see that's the difference.Oh, see that's the difference.
You're running in a non-root cgroup, I think.
You're running in a non-root cgroup, I think.
That also means that your scheduler overhead has way more spinlocks, and in particular, you have that
and in particular, you have that
raw_spinlock_t *cpu_lock = per_cpu_ptr(&cgroup_rstat_cpu_lock, cpu); That's what the AIX docs imply, at least.
That's what the AIX docs imply, at least.
In particular, I find:
In particular, I find:
"isync is not a memory barrier instruction, but the load-compare-conditional branch-isync sequence can provide this ordering property"
ordering property"
so why are you doing "sync/lwsync", when it sounds like "isync/lwsync" (for lock/unlock) is the right thing and would already give memory barrier semantics?
barrier semantics?
Linus