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/gerrit-log@lists.osmocom.org/.
pespin gerrit-no-reply at lists.osmocom.orgpespin has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/25415 )
Change subject: vty sched: add api to force deferred applying
......................................................................
Patch Set 2:
(1 comment)
https://gerrit.osmocom.org/c/libosmocore/+/25415/2/src/vty/cpu_sched_vty.c
File src/vty/cpu_sched_vty.c:
https://gerrit.osmocom.org/c/libosmocore/+/25415/2/src/vty/cpu_sched_vty.c@425
PS2, Line 425: if (applynow) {
> All we allow ourselves to do is to apply some changes immediately, and others only at whatever other natural point in time (bts reconnect, etc.), and we document that via attributes.
That's precisely my point here. User configures it and it is expected to be applied at runtime by the app code, for which each thread calls the related function to apply its config. So it's not generic VTY code or the user deciding when to do the mangling with threads at runtime, but rather the app code asking the infra to apply desired thread option at a specific point of time. If one wants to change the usual thread config, it is expected to be applied next time the process is started. If someone really wants to mangle with thread cpu affinity while the process is running, better go do it with linux tools allowing so (they exist) since you anyway should know what you are doing.
So in general when you use this VTY commands, you are configuring where to pin the threads, but when that actually happens is defined by the app itself. You are simply configuring where to allow each thread.
> "enable" style commands don't change persistent configuration. That's what the configure node and its sub-nodes are for.
I think I wrote there " store it temporarily but not written back to cfg file (have a ->temporary=true)." so I think we agree here? In any case, that's given the event that we really want to use the VTY to apply instantaneous cpu affinity interactively rather than simply configuring it to do so upon startup.
That's my five cents, up to you whether you want to change the state of things here. I'm not for it, but I'm not going to block it. If you want to merge this, then at least provide proper update to the documentation of the cpu affinity section explaining the new behavior and ideas.
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/25415
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: Id8405099e6b316c2e14fb0c9b3c5e80a68a91277
Gerrit-Change-Number: 25415
Gerrit-PatchSet: 2
Gerrit-Owner: Hoernchen <ewild at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge at osmocom.org>
Gerrit-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-Comment-Date: Tue, 14 Sep 2021 09:32:26 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: laforge <laforge at osmocom.org>
Comment-In-Reply-To: pespin <pespin at sysmocom.de>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210914/1c65d18c/attachment.htm>