#linuxcnc-devel Logs

Oct 17 2020

#linuxcnc-devel Calendar

07:57 AM rene_dev_21: seb_kuzminsky are you around?
11:49 AM jepler: anybody enabled CONFIG_NO_HZ_FULL and tried boot parameter no_hz_full=N where N is the highest CPU number? Seems like it could make a nice improvement in scheduling. However, it's not enabled in debian amd64 kernels. https://www.kernel.org/doc/html/v5.3/timers/no_hz.html?highlight=nohz_full
12:07 PM skunkworks: no. sounds interesting...
12:08 PM skunkworks: jepler: question.. on uspace - is there a limit to how large an array can be in a componant? or how would you increase it?
12:09 PM skunkworks: I found variable float shape[50000]; is a limit - much higher and the componat compiles but linuxcnc doesn't launch
12:19 PM rs[m]: skunkworks: are you putting "float shape[50000]" into shared memory?
12:26 PM skunkworks: Umm..
12:26 PM skunkworks: I am just writing a simple comp....
12:26 PM skunkworks: This is a global variable for the comp
12:28 PM rs[m]: what is the error message from startup?
12:31 PM skunkworks: ini_hal_init: ERROR: hal_malloc() failed
12:32 PM skunkworks: which seems like a memory issue - but the normal way to increase hal memory doesn't seem to work
12:32 PM skunkworks: in uspace. (atleast I cannot do it manually)
12:33 PM skunkworks: ulimit -l 20480
12:33 PM skunkworks: bash: ulimit: max locked memory: cannot modify limit: Operation not permitted
12:33 PM skunkworks: if you sudo it - the command isn't found...
12:34 PM cradek: ./src/hal/hal_priv.h:#define HAL_SIZE (75*4096)
12:35 PM cradek: so 50,000 4-byte floats would be 200k of your 300k total available
12:36 PM cradek: if this is a userspace component you could call malloc yourself to get whatever you need (not hal_malloc)
01:33 PM skunkworks: cradek: thanks!
01:34 PM skunkworks: i was playing with the comp scanning in a gcode shape..
01:34 PM skunkworks: it is realtime.
04:00 PM skunkworks: how would I change this limit in an installed setup?
04:22 PM rs[m]: skunkworks: "it is realtime" means rtai?
04:24 PM rs[m]: skunkworks: i think you will have to do a complete rebuild
04:25 PM rs[m]: skunkworks: i'm using (128*4096) on preempt-rt (because of ridiculous amount of IO)
04:29 PM skunkworks: I got the rip version on my laptop working by increasing the HAL_SIZE..
04:29 PM skunkworks: rs[m]: it is uspace
04:29 PM skunkworks: rt_preempt
04:30 PM rs[m]: skunkworks: if you don't need to share in with other components, you could use malloc
04:31 PM rs[m]: s/in/it/
04:31 PM skunkworks: example?
04:31 PM skunkworks: (it only needs to be in this componant..)
04:32 PM rs[m]: instead of float shape[5000] use float shape* and in the init do something like shape = malloc(5000 * sizeof(float));
04:38 PM skunkworks: I will look through some of the existing hal componants and see if I can see the pattern
04:43 PM rs[m]: sorry typoed
04:43 PM rs[m]: instead of "float shape[5000];" use "float shape;" ( before shape, not after)
04:45 PM rs[m]: and before using it, in rtapiappmain, do something like "shape = malloc(5000 * sizeof(float));"
04:49 PM rs[m]: maybe i misunderstood
04:49 PM rs[m]: just use malloc() instead of hal_malloc() ;)
05:03 PM skunkworks: I kinda understand. just have to figure out how... slightly above my pay grade ;)
05:04 PM skunkworks: (because this is a pretty basic hal component)
05:06 PM skunkworks: thank you!
05:28 PM jepler: skunkworks: In uspace, all memory is (intended to be) "locked" : res = mlockall(MCL_CURRENT | MCL_FUTURE);
05:28 PM jepler: however, the limit on locked memory is also intended to be unlimited: int res = setrlimit(RLIMIT_MEMLOCK, &unlimited);
05:30 PM jepler: but yeah I think the operative limit is the HAL shared memory area. It's not strictly _necessary_ but comp will put the "variable" in the shared memory area. It would be an improvement to comp to place the data elsewhere.
05:30 PM jepler: (it's nice and simple to do it that way, because for rtai / kernel mode realtime this means there's no need to find where to free the memory, as long as the main hal memory area is freed)
05:42 PM skunkworks: can you malloc a variable in a comp?
05:46 PM skunkworks: don't laugh too hard.. https://pastebin.com/QgkJcVqu
05:48 PM skunkworks: the variable float shape[100000] works in rip because I can change the Hal_size and re-compile
05:49 PM skunkworks: but if I understand it right - I should be able to allocate the memory within the hal componant.
05:57 PM rs[m]: look at "option extrasetup yes" and "option extracleanup yes" for where to put malloc / free
05:57 PM rs[m]: hmm. something messes with the underscore characters...
06:04 PM skunkworks: ok - I will do some more research.
06:28 PM rs[m]: completely untested https://paste.debian.net/1167630/
06:32 PM skunkworks: rs[m]: thanks! I will play with it
06:36 PM skunkworks: http://electronicsam.com/images/greenmachine/IMG_20201017_183012.jpg
06:36 PM skunkworks: (running a minimum array on installed linuxcnc)
06:42 PM Tom_L: :)