samba profiling and pcp pmda

James Peach jpeach at
Thu Apr 12 15:41:28 GMT 2007

On 12/04/2007, at 1:15 AM, Alison Winters wrote:

> 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.

No the benefit is in reducing the complexity of allocation. As you  
allocate more different types of object, the code moves closer to  
being a general purpose allocator. That's not something I want to  
write or maintain, and as it becomes more complex it is harder to grow  
the mmap.

>>> 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?

That depends on exactly what you want.

> 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.

If you think that smbprofile.h is OK for client apps, then it should  
be standalone. IMHO smbprofile.h is not the right solution for this,  
and from the sounds of the above, you have some changes.

James Peach | jpeach at

More information about the samba-technical mailing list