This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgDear list,
I did some more experiments.
On Sat, Sep 26, 2020 at 07:50:14PM +0200, Harald Welte wrote:
> == launching the program in gnome-terminal
>
> @usecs:
> [2, 4) 32387 |@@@ |
> [4, 8) 457668 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
> [8, 16) 44408 |@@@@@ |
> [16, 32) 466 | |
> [32, 64) 63 | |
> [64, 128) 9 | |
> [128, 256) 3 | |
> [256, 512) 53 | |
> [512, 1K) 0 | |
> [1K, 2K) 0 | |
> [2K, 4K) 0 | |
> [4K, 8K) 1 | |
> [8K, 16K) 0 | |
> [16K, 32K) 0 | |
> [32K, 64K) 39 | |
> [64K, 128K) 125 | |
> [128K, 256K) 0 | |
> [256K, 512K) 0 | |
> [512K, 1M) 0 | |
> [1M, 2M) 0 | |
> [2M, 4M) 0 | |
> [4M, 8M) 0 | |
> [8M, 16M) 0 | |
> [16M, 32M) 0 | |
> [32M, 64M) 0 | |
> [64M, 128M) 0 | |
> [128M, 256M) 0 | |
> [256M, 512M) 0 | |
> [512M, 1G) 0 | |
> [1G, 2G) 1 | |
>
> So we can see that gnome-terminal tends to be faster on most stderr-writes,
> but at the expens of introducing a few long-delays in the 32..128ms bucket.
>
> The other idea would be to do our own buffering using osmo_wqueue() on
> the raw, unbuffered stderr-fd, which would then be in non-blocking mode
> and handled vis osmocom select. We'd have to add some kind of limit for
> that buffer in order to avoid OOM situations.
I just implemented that. Results are promising.
This is with gnome-terminal where above we had the significant number of 64..128ms
blocking delays. Now:
@usecs:
[1] 404920 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[2, 4) 308383 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ |
[4, 8) 3191 | |
[8, 16) 1434 | |
[16, 32) 1438 | |
[32, 64) 65 | |
[64, 128) 22 | |
[128, 256) 9 | |
[256, 512) 9 | |
so no more than 512us for any log output line (which is within the process,
allocating a msgb + enqueueing it to the write_queue). We have to be a bit
careful here, in order to prevent re-entrancy problems. For example, write_queue
currently wants to log if the queue is full, which obviosly causes infinite
recursion.
We make logging more expensive this way, as we add a msgb allocation + memcpy
to each log statement. At the same time, we remove the potential of any
write-blocking, which is probably worth it.
There are some other side-effects, though: stderr-logging no longer works
for small programs tat don't ever call osmo_select_main(). So maybe we need
to support both the old blocking as well as the new non-blocking method?
But how do we make sure everyone gets the best default behavior? Start
with the blocking/buffered I/O and switch to the write_queue backend on
the first call to osmo_select_main()?
What do you think?
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)