Hi Alan,
I'd like to raise this topic again; apparently my last changes were
"clueless". However, Andrew's benchmarks showed that we lose 10% overall
performance due to our allocator - we can go much faster if we simply
use glibc()'s native allocator.
Although 10% performance isn't much, it means we can do 10% better on
fail-over latency, as well!
The goal of the above patch was to separate the bucket allocator from
our builtin checks and to be able to enable/disable them separately, for
being able to pin-point where exactly that overhead was spent. What I
believe it did. (And, given that it was release time, I didn't want to
refactor the code massively, but merely introduce some defines which
didn't change the resulting code at all, unless enabled.)
We've tried discussing this off-line in the past, and you said my code
didn't compile, or that I had mismatching #define names, which seems to
imply we were talking about different code, because neither of which is
true for this changeset ;-)
I do believe that the bucket allocator and our checks ought to be
optional, separately. For a shipped version, the performance difference
is significant.
So, what approach would you fancy? I'm willing to code it to your
liking, but would prefer not to appear clueless.
Sincerely,
Lars
--
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge."
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
