On Mon, 2010-01-18 at 15:41 +0000, Alan Cox wrote: > On Mon, 18 Jan 2010 16:24:07 +0100 > Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > On Mon, 2010-01-18 at 17:19 +0200, Avi Kivity wrote: > > > > I would not advice that, just mlock() the text and data you need for the > > > > real-time thread. mlockall() is a really blunt instrument. > > > > > > > > > > May not be feasible due to libraries. > > > > Esp for the real-time case I could advise not to use those libraries > > then, since they're clearly not designed for that use case. > > In "hard" real time cases an awful lot of libraries have things like > memory allocations in them and don't care about stack growth which can > cause faults and sleeps. The memory allocator if you are running threaded > was not real time priority aware either last time I checked so the > standard libraries are not going to give the behaviour you want unless > you have a proper RT environment, and even then it may be a bit iffy here > and there. I'm quite aware of that, which is why we recommend people to pre-allocate, mlock() and pre-fault everything in advance and make sure the RT thread doesn't touch any data/text outside of that and uses a limited set of system calls. You can also do that for stacks using pthread_attr_setstack(). -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
