Re: [Xenomai] XDDP socket, any memory allocation when sendto() is called?

[Philippe Gerum <rpm@xenomai.org>]

On 05/13/2016 09:42 PM, Steve B wrote:
> 
> 
> On Fri, May 13, 2016 at 11:45 AM, Philippe Gerum <rpm@xenomai.org
> <mailto:rpm@xenomai.org>> wrote:
> 
> 
>     Maybe. You should have a look at the vmstat output for a while (e.g.
>     vmstat -a 1).
> 
>     Cobalt gets all the core memory it needs from __vmalloc() since 3.0.2
>     (was __get_free_pages() in earlier 3.x releases), then stacks its own
>     allocation scheme on top of this (cobalt/kernel/heap.c). So the memory
>     usage on the RT side appears as one shot allocations only for getting
>     the initial memory underlying the real-time heaps.
> 
>     --
>     Philippe.
> 
> 
> Thanks, this has been informative for me on a few more things to be
> looking at during development cycle, if a little off topic for this
> mailing list.
> I think I've actually found what's happening. I went ahead and wiped out
> all of the log files even while the process was still running, and found
> that the memory is freed up immediately! So the memory consumption is in
> the files I'm saving, even though they're supposed to go to the on board
> flash filesystem. I understand that they might be stored in RAM
> initially before getting synced over to flash, but kind of interesting
> that the upper bound on that is almost the entire RAM. There may be an
> OS setting somewhere that sets a bound, or an occasional "sync" system
> call might help free that memory up if I really need to for some reason.
> 
> Now that I've ruled out the XDDP and found what's actually happening, it
> becomes more of a Linux question than a Xenomai thing but thanks for
> helping me narrow it down!
> 

As Gilles pointed out, the fs cache is likely eating that memory. You
could try flushing it, before looking at the available free memory again:

# echo 1 > /proc/sys/vm/drop_caches

-- 
Philippe.