m_tag, malloc vs uma

[Karim Fodil-Lemelin]

Robert Watson wrote:
> On Fri, 10 Apr 2009, Karim Fodil-Lemelin wrote:
>
>> Thank you for the answer, clear and concise. I asked the question 
>> because I had modified pf_get_mtag() to use uma directly in the hope 
>> that it would be faster then calling malloc. But since pf_mtag is 
>> 20bytes, malloc will end up using a fixed 32bytes zone and I 
>> shouldn't expect much speed gain from using something like (except 
>> some savings from not having to select the 32bytes zone):
>
> There is another small overhead, the critical section used to protect 
> the consistency of the per-CPU malloc type alloc and free counters, 
> but it's also very small.
>
> I think it would be desirable to make a change to more flexible m_tag 
> types for 8.0, but I'm not sure I have time to implement/test it.  Is 
> this something you might be interested in working on?  I'm thinking of 
> basically replacing the m_tag_free pointer with a pointer to a small 
> vector of operations, possibly something along these lines:
>
> struct m_tag_ops {
>     void        (*m_tag_free)(struct m_tag *);
>     struct m_tag    (*m_tag_copy)(struct m_tag *);
> };
>
> If the m_tag_ops pointer is NULL, we go with today's default 
> (requiring minimal change of existing consumers).  I'm not sure if 
> there are any other function pointers we'd need at this point? 

Is the m_tag_copy an 'overloaded' function for the current m_tag_copy or 
something else? Now it could also be interesting to have another 
function pointer to overload m_tag_alloc to give more control over which 
zone the user wants its tags from (ex: pf_mtag ...). The interest is 
there not sure if the schedule will allow it but that depends if the new 
m_tag designs allows me to squeeze some performances in.

Karim.