Add minimal_memory_lock package

[carlossvg]

No description provided.

[carlossvg]

FYI @shuhaowu @razr @christophebedard @LanderU @JanStaschulat I created a first PR with the memory lock example. Could you take a look and provide some feedback? Thanks.

[shuhaowu]

Just as a note, I have my memory locking example in my demo app: https://github.com/shuhaowu/rt-demo/blob/b33a8be/libs/rt/src/app.cc#L15-L16

[shuhaowu]

Looks mostly good, but two main comment:

• Probably should use RUSAGE_THREAD instead of RUSAGE_SELF to avoid the need for the --sleep.
• I would consider just calling mlockall all the time and not be able to turn it off. It seems to me that any RT thread should always mlockall and configure malloc. Having an option to turn it off may make it confusing for people who want to implement this in their program, as they won't know when and why they should turn off configure_memory_behavior (which is never?). This also removes the need to memset during memory reservation.

[shuhaowu]

Why is this function called and the return value not consumed?

[carlossvg]

It's just to initialize the static members from the functions. Since this is not obvious I will change this. I can create a MemoryPageFaultCount class with reset and get functions to make this cleaner.

[shuhaowu]

Minor nitpick: Is it needed to store the pagefault as a state? I just store the page fault count in local variable (A) at one point in the code, do some stuff, and then get the counts again in another local variable (B). I then subtract B - A. Like https://github.com/shuhaowu/rt-demo/blob/7116d52/docs/prefault-experiments/prefault-test.cc#L80

[carlossvg]

I'm checking the page faults inside the node callback so I need to save them either as part of the Node class or somewhere else. I started using the same approach as the rt wiki, so this is why I was using storing them inside the function itself.

[shuhaowu]

Ah maybe what you have is fine. Maybe add a comment to call out the fact that you're initialization?

[carlossvg]

I will create a class so it's easier to understand.

[shuhaowu]

Sorry this PR review dragged out to 30 comments, didn't intend it to be like that 😅 ..

That said, I want to pull this comment out of that thread to keep things a bit more clear (if that's possible):

This is how it was implemented at the begging. Then, I started debugging I wanted to compare with and without memory lock. In fact, I think is very helpful for the users to compare both cases.

I see the following options:

1. Remove all the options, keep it minimal
2. Keep all the options. Add comments explaining the memory has to be locked for real-time behavior.
3. Create a separate executable without locking the memory

In this other comment, you mentioned that if RT is needed for the DDS thread, then you need a sleep (which is kind of a bug from RMW..). There are some commonalities here:

I think we should figure out who the target audience for this code is. Right now it feels like code that proves that memory locking is working (almost like unit-tests). Maybe, we should target RT app developers instead who are probably more interested in a "sample app framework" for ROS? Something with all the scheduling and memory setup. We can still put some logging about page faults, as that could be the "sample application code", if that makes sense. This way you don't need any of the options. We can quickly document all the things in the README. I also have a blogpost coming that explains all these options in hopefully a week.

The "sample app approach" is also what my repo is trying to do for non-ROS apps.

[carlossvg]

@shuhaowu @LanderU I updated the example. These are the main changes:

• Moved locking and rusage functions to header files
• I extended the README with some instructions (I'm thinking about using asciinema)
• I added one additional option to simulate allocations on the heap during runtime. This helps to explain why using a preallocated memory pool could be useful.

[shuhaowu]

Thanks for working this through!

[carlossvg]

@shuhaowu Thanks a lot for the review. I added some asciicenema recordings to show what the output looks like. It provides a nice visualization in github pages. See the result here: https://ros-realtime.github.io/ros2-realtime-examples/minimal_memory_lock/