Mailing List Archive: heartbeat, dynamic module loading, and memory locking

heartbeat, dynamic module loading, and memory locking

Sep 2, 2000, 3:00 PM

Post #1 of 3 (810 views)

Hi,

Marcelo's dynamic module loading code for heartbeat is now in CVS.

Before I put it in, I couldn't lock all the heartbeat processes into memory
on my machine. (Linux didn't complain, it just didn't do it, as witnessed
by some of the processes not having an 'L' in ps).

Now, even though I have 3 heartbeat media defined on this cluster, it all
locks into memory just fine. (my machine has 128M of RAM)

This is great. Thanks Marcelo!

However, since heartbeat is dynamically linked and does an mlockall() call,
this locks *all* of libc into memory. I understand that to be a lot of
memory.

One option would be to statically link heartbeat, so that it didn't try and
lock all of libc into memory. This would decrease the amount of stuff
nailed into memory (perhaps significantly), since only the parts of libc
used by heartbeat would then be locked into memory.

On the other hand, other applications wouldn't benefit from this like they
would from nailing (shared) libc into memory.

Does anyone have any words of wisdom for this situation?

Thanks!

-- Alan Robertson
alanr@suse.com

heartbeat, dynamic module loading, and memory locking [ In reply to ]

lmb at suse

Sep 4, 2000, 6:06 AM

Post #2 of 3 (791 views)

Permalink

On 2000-09-02T16:00:21,
Alan Robertson <alanr@suse.com> said:

> On the other hand, other applications wouldn't benefit from this like they
> would from nailing (shared) libc into memory.
>
> Does anyone have any words of wisdom for this situation?

If it is not avoidable, using the approach from which other applications can
benefit is definetely desireable.

Mind you, we don't want to go the Dan Bernstein route and rewrite libc because
we don't trust it do we ;-)

Sincerely,
Lars Marowsky-Brée <lmb@suse.de>
Development HA

--
Perfection is our goal, excellence will be tolerated. -- J. Yahl

heartbeat, dynamic module loading, and memory locking [ In reply to ]

alanr at suse

Sep 4, 2000, 4:39 PM

Post #3 of 3 (795 views)

Permalink

Lars Marowsky-Bree wrote:
>
> On 2000-09-02T16:00:21,
> Alan Robertson <alanr@suse.com> said:
>
> > On the other hand, other applications wouldn't benefit from this like they
> > would from nailing (shared) libc into memory.
> >
> > Does anyone have any words of wisdom for this situation?
>
> If it is not avoidable, using the approach from which other applications can
> benefit is definetely desireable.
>
> Mind you, we don't want to go the Dan Bernstein route and rewrite libc because
> we don't trust it do we ;-)

Hi Lars,

Good to see you're back!

I've been thinking about providing both versions of heartbeat, and let the
user decide for themselves. This makes it NotMyProblem(tm).

If you have a small amount of memory, and you run applications that don't
make that heavy use of libc, then static linking in heartbeat is the way to
go.

If you have lots of memory, and they use libc a lot, then dynamic linking is
a better bet.

-- Alan Robertson
alanr@suse.com