Hi Philipp,
On 11/25/2013 11:15 AM, Philipp Überbacher wrote:
On Mon, 25 Nov 2013 10:10:37 +0100
Daniel Wagner <wagi@xxxxxxxxx> wrote:
Hi Steven,
I'd like to write up a summary how to write a RT application. Instead
of writing yet another document, I really like to extend (if needed)
this here
https://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application
My memory is quite bad so I am not sure if there is anything missing
on this page, compared with your presentation durin the RTWS.
If you don't mind sharing the slide, I could try to add missing
stuff :)
(Obviously, it will be in Engrish :P)
cheers,
daniel
Hi Daniel, hi list.
I think your mail didn't make it to list so far (at least there is
no Cc).
I would appreciate such a thing (for the time when I finally come
around to write some audio application).
Looking forward to it :)
One thing that's a bit unclear to me: should mlockall() be used with
the MCL_FUTURE flag? Or to rephrase this, does mlockall(MCL_FUTURE)
somehow look ahead and immediately lock all pages the process will ever
need?
According mlockall() man page:
MCL_CURRENT Lock all pages which are currently mapped into the address space of the
process.
MCL_FUTURE Lock all pages which will become mapped into the address space of the process
in the future. These could be for instance new pages required by a growing
heap and stack as well as new memory mapped files or shared memory regions.
If MCL_FUTURE has been specified, then a later system call (e.g., mmap(2), sbrk(2), mal‐
loc(3)), may fail if it would cause the number of locked bytes to exceed the permitted
maximum (see below). In the same circumstances, stack growth may likewise fail: the ker‐
nel will deny stack expansion and deliver a SIGSEGV signal to the process.
Mostlikely you want to use both flags. See also the examples
https://rt.wiki.kernel.org/index.php/Simple_memory_locking_example
https://rt.wiki.kernel.org/index.php/Dynamic_memory_allocation_example
https://rt.wiki.kernel.org/index.php/Threaded_RT-application_with_memory_locking_and_stack_handling_example
Another useful thing would be a (probably incomplete) list of common
calls that are known to cause problems in an rt context.
Absolutely.
cheers,
daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
