On Tue, Mar 5, 2013 at 1:35 AM, Davidlohr Bueso <davidlohr.bu...@hp.com> wrote:
>
> The following set of patches are based on the discussion of holding the
> ipc lock unnecessarily, such as for permissions and security checks:
Ok, looks fine from a quick look (but then, so did your previous patch-set ;)
You still open-code the spinlock in at least a few places (I saw
sem_getref), but I still don't care deeply.
>> 2) While on an Oracle swingbench DSS (data mining) workload the
> improvements are not as exciting as with Rik's benchmark, we can see
> some positive numbers. For an 8 socket machine the following are the
> percentages of %sys time incurred in the ipc lock:
Ok, I hoped for it being more noticeable. Since that benchmark is less
trivial than Rik's, can you do a perf record -fg of it and give a more
complete picture of what the kernel footprint is - and in particular
who now gets that ipc lock function? Is it purely semtimedop, or what?
Look out for inlining - ipc_rcu_getref() looks like it would be
inlined, for example.
It would be good to get a "top twenty kernel functions" from the
profile, along with some call data on where the lock callers are.. I
know that Rik's benchmark *only* had that one call-site, I'm wondering
if the swingbench one has slightly more complex behavior...
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
