Hello,
following the Kamailio Developers Meeting discussions and provided that
GNU/Linux malloc() aligns allocated memory to 16 bytes on x86_64 (64b
CPUs), I just updated the native Kamailio qm (quick malloc - the default
one) and fm (fast malloc) memory managers to also align to 16 bytes:
-
https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.ht…
By default they do it to 16 also for 32b CPUs, the overhead at startup
with default config was rather insignificant (like 5000 bytes for
private memory set to 8MB), so I didn't want to bother that much (that's
also because some 32b CPUs could require larger alignment that the size
of the pointer address), but for flexibility I added the an option to
set the alignment size at compile time with KSR_MEMORY_ALIGN define
(e.g., -DKSR_MEMORY_ALIGN=8UL).
The main benefit at this moment is that Kamailio should be able to use
the OS distribution (e.g., Debian) packaged libwolfssl instead of
bundling and building the library inside it to compile with custom
flags, like it is done now. Also, it is safe for the future to use other
libraries that leverage internally the OS memory alignment size for
specific optimizations.
I also increased the optimize factor to 15, which should speed up a bit
dealing with larger chunks of memory (now up to 32KB, previously was up
to 16KB). Considering that it is more and more common to deal with
larger SIP messages (e.g., a webrtc invite can easily be like 20KB) as
well as tls/encryption needs addition space that the unencrypted udp/tcp.
Hopefully these updates don't have side effects, it was nothing
consistent changed, a few defines and fields to match the new alignment
constraints. But testing is important, try to play with the master and
your configs whenever you have any chance.
Unfortunately the tlsf memory manager seems to be specifically designed
for aligning to 8 bytes, a rather old related issue in that project is
not concluded:
- https://github.com/mattconte/tlsf/issues/16
That means the tls_wolfssl module linked with the officially packaged
libwolfssl has to be used with qm or fm malloc from now on. Or it has to
be built like so far to use tlsf memory manager. The tls/tlsa module can
still be used with tlsf memory manager.
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services
```
CC (gcc) [M ping_endpoint.so] t_cancel.o
CC (gcc) [M ping_endpoint.so] t_fifo.o
In file included from ../../core/ut.h:42,
from t_fifo.c:38:
t_fifo.c: In function 'append2buf':
../../core/dprint.h:321:73: warning: format '%i' expects argument of type 'int', but argument 11 has type 'long int' [-Wformat=]
321 | fprintf(stderr, "%2d(%d) %s: %.*s%s%s%s" fmt, \
| ^~~~~~~~~~~~~~~~~~~~~~~~
../../core/dprint.h:345:25: note: in expansion of macro 'LOG_FX'
345 | LOG_FX(facility, level, lname, prefix, _FUNC_NAME_, fmt, ## args)
| ^~~~~~
../../core/dprint.h:351:25: note: in expansion of macro 'LOG_FL'
351 | LOG_FL(facility, level, NULL, prefix, fmt, ## args)
| ^~~~~~
../../core/dprint.h:354:25: note: in expansion of macro 'LOG_FP'
354 | LOG_FP(DEFAULT_FACILITY, (level), LOC_INFO, fmt, ## args)
| ^~~~~~
../../core/dprint.h:401:45: note: in expansion of macro 'LOG'
401 | # define DBG(fmt, args...) LOG(L_DBG, fmt , ## args)
| ^~~
../../core/dprint.h:405:36: note: in expansion of macro 'DBG'
405 | # define DEBUG(fmt, args...) DBG(fmt , ## args)
| ^~~
../../core/dprint.h:422:16: note: in expansion of macro 'DEBUG'
422 | #define LM_DBG DEBUG
| ^~~~~
t_fifo.c:576:33: note: in expansion of macro 'LM_DBG'
576 | LM_DBG("AVP <%i>: %p\n",avp_name.n,avp);
| ^~~~~~
CC (gcc) [M ping_endpoint.so] t_funcs.o
CC (gcc) [M ping_endpoint.so] t_fwd.o
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3637
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3637(a)github.com>
Hello,
during the Kamailio Developers Meeting 2023 in Dusseldorf early this
week, Victor Seva shared how one can setup own development environment
for facilitating the automatic checks for clang-format and few other
useful bits (e.g., training white spaces) using pre-commit tool. So I
thought it would be useful to shared further to both developers and
users communities (as the later can make patches and pull requests as well).
If I forgot something, Victor should amend me, but the main steps are:
- install pre-commit package (either via apt or via pip3)
- install clang-format (debian/ubuntu should have it as a package)
- go to the folder with git clone of Kamailio source and run:
pre-commit install
The above command can take some time, but it is needed only once.
After that, on evey commit, the checks should be performed a summary
should be presented on screen, like:
$ git commit src/
check yaml...........................................(no files to
check)Skipped
check xml............................................(no files to
check)Skipped
fix end of
files.........................................................Passed
trim trailing
whitespace.................................................Passed
check for merge
conflicts................................................Passed
mixed line
ending........................................................Passed
clang-format.............................................................Passed
If the check of clang-format results in "Failed", like:
clang-format.............................................................Failed
the pre-commit hooks will correct it, so you can just run again the
commit command and the 2nd time should be good to go.
If for whatsoever reasons pre-commit is installed but you need to
ignore/skip the pre-commit hooks, just provide -n or --no-verify to the
commit command, like:
$ git commit -n src/
By using pre-commit hooks, one could easily avoid making pull requests
that are failing to meet the code formatting checks on github portal as
well as ensure that as developer one does no forget to run clang-format
before commit.
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services
Module: kamailio
Branch: master
Commit: 80d1f10507190ae1a42c25f0c173188b8326b5b9
URL: https://github.com/kamailio/kamailio/commit/80d1f10507190ae1a42c25f0c173188…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-10T14:08:09+01:00
core: qm/fm memory align size can be set with define KSR_MEMORY_ALIGN
- flexibility to be set at compile time via make or compiler parameter
---
Modified: src/core/mem/f_malloc.h
Modified: src/core/mem/q_malloc.h
---
Diff: https://github.com/kamailio/kamailio/commit/80d1f10507190ae1a42c25f0c173188…
Patch: https://github.com/kamailio/kamailio/commit/80d1f10507190ae1a42c25f0c173188…
---
diff --git a/src/core/mem/f_malloc.h b/src/core/mem/f_malloc.h
index c05a243af6f..5a9d28ece42 100644
--- a/src/core/mem/f_malloc.h
+++ b/src/core/mem/f_malloc.h
@@ -46,10 +46,15 @@
* can be 32 bits aligned => malloc should return multiple of long long
* aligned memory
* - malloc() on gnu/linux: multiple of 8 or 16 on 64-bit systems
- * - for simplicity settle for 16 always
+ * - for simplicity settle for 16 by default
* - sizeof(fm_frag) must be multiple of ROUNDTO!
*/
+#ifndef KSR_MEMORY_ALIGN
#define ROUNDTO 16UL
+#else
+#define ROUNDTO KSR_MEMORY_ALIGN
+#endif
+
#define MIN_FRAG_SIZE ROUNDTO
diff --git a/src/core/mem/q_malloc.h b/src/core/mem/q_malloc.h
index b3bfaab3689..5b440688af3 100644
--- a/src/core/mem/q_malloc.h
+++ b/src/core/mem/q_malloc.h
@@ -39,10 +39,14 @@
* can be 32 bits aligned => malloc should return multiple of long long
* aligned memory
* - malloc() on gnu/linux: multiple of 8 or 16 on 64-bit systems
- * - for simplicity settle for 16 always
+ * - for simplicity settle for 16 by default
* - sizeof(qm_frag) and sizeof(qm_frag_end) must be multiple of ROUNDTO!
*/
+#ifndef KSR_MEMORY_ALIGN
#define ROUNDTO 16UL
+#else
+#define ROUNDTO KSR_MEMORY_ALIGN
+#endif
#define MIN_FRAG_SIZE ROUNDTO
### Description
I migrate one of our old project on native to KEMI on app_python3 and get strange behavior - after some time kamailio stops processing requests/replies wit message "ksr_request_route/ksr_reply_route not found or is not callable"
### Troubleshooting
After some research with debug=3 and reading debug logs i found, that some of routes i forgot to rename in calls t_on_reply() and t_on_failure() - because they generates "not found or is not callable" in logs too. Also i check all event routes and found that some event_callbacks point to wrong KEMI functions.
Events of the form (which gave me the idea that it was the wrong names)
DEBUG: 887937087 INVITE app_python3 [python_exec.c:93]: apy_exec(): ksr_onrl_MANAGE not found or is not callable
DEBUG: app_python3 [python_exec.c:93]: apy_exec(): ksr_dialog_event not found or is not callable
presents in logs very rarely (I saw them only after hours of debugging) even after restart.
For me its look like that nonexisted routes completly stops interpretator and block all subsequent processing in the fork and kamailio very rarely has time to log it.
When i use right names of functions it works well and no "ksr_request_route/ksr_reply_route not found or is not callable"
PS: KSR.tm.t_on_branch() with wrong route generates normal exception and nonblock execution
#### Reproduction
Just use wrong names in KSR.tm.t_on_reply()/KSR.tm.t_on_failure() or modparam event_callback in any module (i got it with dispatcher and dialog)
#### Log Messages
Exception that generates by wrong function in KSR.tm.t_on_branch()
ERROR: 63586697 BYE app_python3 [python_support.c:156]: python_handle_exception(): apy_exec: ksr_request_route((null)): Unhandled exception in the Python code:
AttributeError: 'kamailio' object has no attribute 'ksr_br_MANAGE'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/etc/kamailio(a)REGION/python/request_route.py", line 38, in ksr_request_route
if self.ksr_WITHINDLG() == -255:
File "/etc/kamailio(a)REGION/python/ksr_WITHINDLG.py", line 27, in ksr_WITHINDLG
return self.ksr_RELAY()
File "/etc/kamailio(a)REGION/python/ksr_RELAY.py", line 17, in ksr_RELAY
if KSR.tm.t_relay() < 0:
SystemError: <built-in function t_relay> returned a result with an error set
### Possible Solutions
Use rigth names
### Additional Information
version: kamailio 5.7.1 (x86_64/linux) 4238e4
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 4238e4
compiled on 00:00:00 Sep 13 2022 with gcc 11.3.1
version: kamailio 5.6.4 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 10.2.1
* **Operating System**:
PRETTY_NAME="Oracle Linux Server 9.2"
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3572
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3572(a)github.com>