samba profiling and pcp pmda

[Alison Winters]

James Peach wrote:
> I mean to use one mmap per record type. The current scheme is ugly
> because it really doesn't want to be a proper allocator but it has to
> deal with 2 different sizes of records in the mmap. If you have a
> separate mmap for each record type, the allocator goes back to being
> nice and simple.
> 
Surely the only benefit of splitting out record types per-file (i.e.
client and share) is that you can step through the allocated records as
an array rather than a linked list?  Is there really much performance
gain there?  I imagine the code to step through the list and add/remove
records will stay pretty much the same.

>> That's in the pipeline :)  What i'm planning is to just add a bit of
>> extra magic to the existing Samba profiling macros that allow us to
>> split it out per-client and per-share along with the existing recording
>> of global counts and times.  I'm pretty sure this is going to be fairly
>> elegant and small if i get it right.
> That sounds neat. It would be great if you had some code to reconcile
> the existing profiling stats with these metrics.
> 
That's pretty much the plan.  Each class of extended stats when summed
together should equal the existing profiling stats (in theory).

>> I have a separate patch which i can't submit yet (it's copyright SGI)
>> that splits out all of the current profiling statistics into smaller
>> groups that we can turn on and off independently.
> Do you mean the stats that currently live in the sysv shared memory
> segment?
> 
Yep.

> IIRC you only get a big performance hit when you are timing operations.
> You can probably avoid this (to some degree) by using platform-specific
> timers.
> 
I'll look into it, thanks :)  Right now there's just the regular
GetTimeOfDay calls.

> IMHO, the Samba PMDA belongs in the PCP tree, not in the Samba tree.
> Since you are going to be the one maintaining it, it's easier all round
> if it lives there. We can simply remove the existing PMDA from the Samba
> tree.
> 
Sure that makes sense.  So, with that in mind, what's the best way to
export a Samba header file for consumer apps?  For instance, in the case
of the smbprofile.h header, it uses stuff like enum flush_reason_enum
and typedef BOOL which are defined elsewhere that third-party apps can't
see.  Is the correct approach to write a script that munges the header
into something that could potentially stand alone in a "devel" package?

Alison