dtrace discuss - Sep 2007 - a piece of code in dtrace pseudo device

Dear all:

In dtrace.c, function dtrace_probe_create(), there''re a piece of code:

id = (dtrace_id_t)(uintptr_t)vmem_alloc(dtrace_arena, 1,
     VM_BESTFIT | VM_SLEEP);

id is uint32_t, and I think id is used as an index to array dtrace_probes[]
but why not just use id = cur_value + 1, cur_value is a global variable to
record the lastest id?
Is this a trick? for what?

Thanks :)


Regards,
TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070905/8f620906/attachment.html>

$ALU=](B TaoJie writes:
> In dtrace.c, function dtrace_probe_create(), there''re a piece of
code:
> 
> id = (dtrace_id_t)(uintptr_t)vmem_alloc(dtrace_arena, 1,
>      VM_BESTFIT | VM_SLEEP);
> 
> id is uint32_t, and I think id is used as an index to array dtrace_probes[]
> but why not just use id = cur_value + 1, cur_value is a global variable to
> record the lastest id?
> Is this a trick? for what?
Using the vmem allocator to allocate integers is fairly common
practice in Solaris.  It provides a number of things that
"cur_value++" doesn''t provide; among them:

  - Inexpensive (no scanning) reuse of free low numbers, which is
    important if you''re allocating array indicies. 
"cur_value++" just
    grows without bound and provides no reuse.

  - Free debug tools in mdb and statistics in kstat.

  - Support routines for walking the list of allocated integers
    (iterators) and test/assertion functions for checking allocations.

  - Locking for MT -- your ''cur_value'' example would be
incorrect for
    most kernel uses in Solaris if it didn''t include a mutex.

  - Callbacks for allocation of new integers, which can be used to
    resize indexed arrays when needed.

  - Sleeping and non-sleeping allocation schemes; useful for different
    operating contexts.

It''s also simple.

There are probably more advantages that I can''t think of at the
moment.  ;-}

-- 
James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

oh! i see~
it''s a really useful trick.

thank you, James

btw, _Locking for MT_, is vmem''s internal lock schema expensive?
compared with a single global mutex assigned with the
''cur_value'' .


Regards,
TJ


2007/9/5, James Carlson <james.d.carlson at
sun.com>:
>
> ?? TaoJie writes:
> > In dtrace.c, function dtrace_probe_create(), there''re a piece
of code:
> >
> > id = (dtrace_id_t)(uintptr_t)vmem_alloc(dtrace_arena, 1,
> >      VM_BESTFIT | VM_SLEEP);
> >
> > id is uint32_t, and I think id is used as an index to array
> dtrace_probes[]
> > but why not just use id = cur_value + 1, cur_value is a global
variable
> to
> > record the lastest id?
> > Is this a trick? for what?
>
> Using the vmem allocator to allocate integers is fairly common
> practice in Solaris.  It provides a number of things that
> "cur_value++" doesn''t provide; among them:
>
> - Inexpensive (no scanning) reuse of free low numbers, which is
>    important if you''re allocating array indicies. 
"cur_value++" just
>    grows without bound and provides no reuse.
>
> - Free debug tools in mdb and statistics in kstat.
>
> - Support routines for walking the list of allocated integers
>    (iterators) and test/assertion functions for checking allocations.
>
> - Locking for MT -- your ''cur_value'' example would be
incorrect for
>    most kernel uses in Solaris if it didn''t include a mutex.
>
> - Callbacks for allocation of new integers, which can be used to
>    resize indexed arrays when needed.
>
> - Sleeping and non-sleeping allocation schemes; useful for different
>    operating contexts.
>
> It''s also simple.
>
> There are probably more advantages that I can''t think of at the
> moment.  ;-}
>
> --
> James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
> Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070905/a3ca7f92/attachment.html>

$ALU=](B TaoJie writes:
> oh! i see~
> it''s a really useful trick.
> 
> thank you, James
> 
> btw, _Locking for MT_, is vmem''s internal lock schema expensive?
> compared with a single global mutex assigned with the
''cur_value'' .
The vmem module uses a mutex per vmem_t, which means it should be the
same as the ''cur_value'' approach.  See
$SRC/uts/common/os/vmem.c.

-- 
James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

On Wed, 2007-09-05 at 09:30 -0400, James Carlson wrote:
> The vmem module uses a mutex per vmem_t, which means it should be the
> same as the ''cur_value'' approach.  See
$SRC/uts/common/os/vmem.c.
But see also the "quantum caching" description in section 1.8 of the
block comment; allocations made from the cache avoid touching the
vmem_t''s mutex and instead use a per-cpu cache protected by a per-cpu
mutex, reducing cache line contention and improving scalability.  

					- Bill