On 2007-02-22T06:55:37, Alan Robertson <[EMAIL PROTECTED]> wrote:
> It doesn't mean that AT ALL. Failover time is normally 90% dominated by
> resource agent time. And increasing CPU time in a multi-process,
> multi-processor situation where networking delays and scheduling delays
> are typically higher than CPU time means that even the wall-clock delay
> that isn't due to resource agents isn't probably more than 5% at most.
> If resource agents are 90% of that time, then the delay is probably more
> like .5%.
That much is certainly true.
> Really? It has caught dozens of bugs. Different tools find different
> bugs. None are perfect. Somehow you're saying that we should take
> weapons for finding bugs out of our arsenal because when Andrew disables
> them, they don't find any bugs for him.
Has it caught bugs recently?
And no, I'm not saying to rip it out. I'm saying to disable it for
production shipments, so the question becomes: Has it caught any bugs on
production systems?
For CTS runs and stuff, the malloc safeguards are good. One might even
consider making/leaving them as the default.
I totally don't see the point of our own allocator, given that glibc's
one is obviously - that much the numbers clearly show - significantly
faster, even if the overall impact may be small. So, why maintain it?
It's pointless by now - it was useful once, but the system libraries
have become better.
I don't object to the safeguards code. I object to the allocator. That
bit no longer makes sense.
And, for production systems, even the safeguards are questionable,
because those bugs have all been caught during debugging.
I know this is your code, and you're attached to it, but please at least
address the matter of the safeguards and having our own allocator
separately.
Sincerely,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
