pcp
[Top] [All Lists]

Re: [pcp] How should we approach the loading of the IB pmda as a LOCAL c

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: [pcp] How should we approach the loading of the IB pmda as a LOCAL context DSO?
From: Martin Hicks <mort@xxxxxxxx>
Date: Wed, 24 Mar 2010 17:38:54 -0400
Cc: Corneliu Boac <cboac@xxxxxxx>, pcp@xxxxxxxxxxx
In-reply-to: <1269461847.16867.25.camel@xxxxxxxxxxxxxxxx>
References: <4BAA42D1.4020507@xxxxxxx> <1269461847.16867.25.camel@xxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Thu, Mar 25, 2010 at 07:17:27AM +1100, Ken McDonell wrote:
> OK, there are several points here ...
> 
> 1. this looks like an unintended fallout from moving the IB and cluster
> PMDAs out of the main PCP build ... HAVE_IBDEV never gets set in the PCP
> tree, nor indeed in the pcp-pmda-infinband tree.

Correct.  I failed to test this properly.

> 2. I don't understand the "cluster pmda failed to load the ib pmda dso"
> part ... there should not be any nested dependency like this in the
> pmdas ... it is possible the cluster pmda cannot fetch the ib metrics if
> they appear in the cluster pmda's config file, but that is not likely to
> be related to anything involving PM_CONTEXT_LOCAL ... Mark, please jump
> in here if I've got this wrong.

The cluster PMDA client (pmclusterd) uses PM_CONTEXT_LOCAL to load the
linux and ib .so's in order to collect and push the metrics to the
server PMDA without running the full PMCD process.

Unfortunately, the support needs to be in libpcp.so in order for LOCAL
contexts to work.

> 
> 3. PM_CONTEXT_LOCAL is a complete hack.  It was "invented" before the

I knew that it was a hack.  Thanks for the history lesson...

> Now I'd prefer to see PM_CONTEXT_LOCAL die.
> 
> I think Nathan has some real world cases where it is useful to be able
> to collect performance data on a specific host without needing
> infrastructure and sys admin cycles to ensure pmcd keeps running.
> 
> So if we are to keep PM_CONTEXT_LOCAL, then I support Corneliu's
> suggestion that we should define new API support to add entries to
> dsotbl[] at run-time ... but how would this work with something like
> pminfo, where the metrics are arbitrary and the PCP client does not
> really know _which_ PMDAs need to be loaded into the local context?
> 
> I think we need some design by argument here.

I pushed Cornel to make this post as a way to introduce himself to the
community.  I know this isn't exactly a gentle introduction into the
world of PCP :)

I honestly hadn't thought much further than a case like the cluster PMDA
that (ab)uses the LOCAL context in order to collect metrics from
pre-definied PMDAs..  Maybe LOCAL is a hack and we should not try to
design for the general case PMAPI application (like pminfo).  Can we
just limit it to a special case, where the PMAPI client is
smart enough to know in advance which PMDAs it needs to load via
the yet-to-be-designed dsotbl[] API?

mh

> 
> On Wed, 2010-03-24 at 11:50 -0500, Corneliu Boac wrote:
> > Hello PCP group:
> > 
> > I have ran into a PCP bug: the cluster pmda failed to load the ib pmda dso.
> > How should we approach the loading of the IB pmda as a LOCAL context DSO?
> > Should we just permanently add it to the dsotab like in the following patch,
> > or should we rethink the dsotab and allow it to grow dynamically via a new 
> > API?
> > ===========================================================================
> > diff -uprBw pcp-3.1.1.sgi.orig/src/libpcp/src/GNUmakefile 
> > pcp-3.1.1.sgi/src/libpcp/src/GNUmakefile
> > --- pcp-3.1.1.sgi.orig/src/libpcp/src/GNUmakefile   2010-02-25 
> > 15:07:18.000000000 -0600
> > +++ pcp-3.1.1.sgi/src/libpcp/src/GNUmakefile        2010-03-24 
> > 09:47:08.000000000 -0500
> > @@ -91,11 +91,8 @@ else
> >  kernel_pmda_dso    = $(TARGET_OS)
> >  endif
> >  
> > -ifeq ($(HAVE_IBDEV),1)
> > +# the pmdacluster needs the ib entry into the dsotab (even if HAVE_IBDEV 
> > is not defined by default)
> >  infiniband_pmda_dso = ib
> > -else
> > -infiniband_pmda_dso =
> > -endif
> >  
> >  dsotbl.h:  $(TOPDIR)/src/pmns/stdpmid 
> >     echo '/* This file is automatically generated by build' > $@
> > ===========================================================================
> > 
> > 
> > After I apply this patch the libpcp/src/dsotbl.h looks like this:
> > ---------------------------------------------------------------------------
> > /* This file is automatically generated by build
> >  *
> >  * It contains list of DSO, supported by the CONTEXT_LOCAL
> >  */
> > static __pmDSO dsotab[] = {
> > #define  LINUX_DSO 60
> >     { 60, "linux/pmda_linux.so", "linux_init" },
> > #define  IB_DSO 91
> >     { 91, "ib/pmda_ib.so", "ib_init" },
> > #define  MMV_DSO 70
> >     { 70, "mmv/pmda_mmv.so", "mmv_init" },
> > #define  SAMPLE_DSO 30
> >     { 30, "sample/pmda_sample.so", "sample_init" },
> > };
> > static int  numdso = (sizeof(dsotab)/sizeof(dsotab[0]));
> > ---------------------------------------------------------------------------
> > 
> > 
> > Thank you,
> > Cornel
> > -- 
> > Corneliu Boac - Software Engineer
> > Silicon Graphics International
> > 2750 Blue Water Road
> > Eagan, MN 55121
> > Phone: (651)683-7900
> > E-mail: cboac@xxxxxxx
> > 
> > _______________________________________________
> > pcp mailing list
> > pcp@xxxxxxxxxxx
> > http://oss.sgi.com/mailman/listinfo/pcp
> > 
> 
> 
> _______________________________________________
> pcp mailing list
> pcp@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/pcp

<Prev in Thread] Current Thread [Next in Thread>