Messages in this thread | | | Subject | Re: [RFC] mlock/stack guard interaction fixup | From | Peter Zijlstra <> | Date | Mon, 23 Aug 2010 19:59:45 +0200 |
| |
On Mon, 2010-08-23 at 10:34 -0700, Linus Torvalds wrote: > I suspect that if you use mlock for _any_ other reason than protecting > a particular very sensitive piece of information, you should use > mlockall(MCL_FUTURE). IOW, if you use mlock because you have realtime > issues, there is no excuse to ever use anything else, imho. And even > then, I guarantee that things like copy-on-write is going to be > "interesting". > > I realize that people hate mlockall() (and particularly MCL_FUTURE), > and yes, it's a bloated thing that you can't reasonably use on a large > process. But dammit, if you have RT issues, you shouldn't _have_ some > big bloated process. You should have a small statically linked server > that is RT, and nothing else.
Us real-time people have been telling people to not use mlockall() at all.
While small !glibc statically linked RT components using shared memory interfaces to !RT apps could work its not how people actually write their apps. They write big monolithic threaded apps where some threads are RT.
[ in part because there doesn't seem to be a usable !glibc libpthread/librt implementation out there, in part because people use crap like Java-RT ]
| |