24 May
2013
24 May
'13
1:07 a.m.
On 5/24/13 12:00 AM, Daniel-Constantin Mierla wrote:
On 5/23/13 10:45 PM, Victor Seva wrote:
2013/5/23 Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
First about the pv_cache - it is a hash table with specs
of pvs used
in config file. Not all pvs are using the cache yet, but should be
migrate to it. The nebefit is that if a same pv is used more than one,
only one spec is stored in cache. For example, if there will be no pv
cache used, if you have 10 of $ru, used memory is 20*sizeof(pv_spec).
If pv cache will be used everywhere, the will be one pv_spec and 10
pointers to it. Because the size of pvspec is much larger than pointer
size, it obviously results in lower memory usage. More that that, if
one needs to parse a pv name at runtime, will not allocate memory each
time, but only first time when added to cache, avoiding memory leak
because some pv_spec have dynamic structure and no free function.
The pv_cache contains items of:
{
pvname
pvspec
...
}
A lookup by pvname in pv_cache returns the address of pvspec in the
above structure.
If the config interpreter uses pv_cache, you get access to pointer of
pvspec field. You can use structure offset to get the start of the
item and from there pvname, First a general recommendation: try to avoid
patching core that much
for
non-common use cases.
Sure. I was just trying to see how this could be done. I
don't want to
mess with the core. :-)
[snip]
At this moment, I think a good solution could be:
[snip]
- update the interpreter to use pv cache instead
of own spec per pv
(I can
do it, being in my list and hopefully is no big change)
I will try to do it myself
just to get familliar with this area. Let's
see how it goes.
- if this feature is enabled in debugger module,
it will create a
hash table
where to index pv set functions by pointer and point to the cache item
- this index has to be created in child_init with rank PROC_INIT to
be sure
all pvs were resolved to cache item
Sorry. But I don't get this. Can you,
please, explain me the rationale
behind this hash table?. but because cache is not used name,
wanted to say: "but because the cache is not used everywhere" -- also
some modules use core actions from inside the code, therefore you search
for pointer in cache, you don't find, then print $unknown...
what you get from config interpreter can be a
standalone pointer and
will result in segmentation fault.
You can lookup the pointer in the pv_cache, by iterating through all
slots until a match. Could be good/fast enough for debugging. I was
thinking of using a hash table to index needed pv_cache items.
A virtual example of config:
$x1 = $x2 + $x3 + $x4;
xlog("$x5 $x6 $x7");
$x8 = $x1 + $x9;
$x1 = $x10 + $x11 + $x4;
The pv cache will have 11 items, but you need to know only the name of
two pvs: $x1 and $x2, because the others are not assigned. To speed
up, you look first for the pointer to $x1 on debugger hash table, it
is not found, iterate in pv cache, find it and store the pointer in
debugger hash table so next time you need it, you find it quickly.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
* http://asipto.com/u/katu *