On Wed, 2007-08-29 at 09:29 -0400, Daniel Drake wrote:Daniel: in a response, Juergen Beisert asked if you'd tried mlock() [mlockall() would probably be a better choice] to lock your application into memory. That would require modifying the application. Don't know if you want to do that. Back in Feb'07, I posted an RFC regarding [optionally] inheriting mlockall() semantics across fork and exec. The original posting is here: http://marc.info/?l=linux-mm&m=117217855508612&w=4 The patch is quite stale now [against 20-rc<something>], but shouldn't be too much work to rebase to something more recent. The patch description points to an ad hoc mlock "prefix command" that would allow you to: mlock <some application> and run the application as if it had called "mlockall(MCL_CURRENT| MCL_FUTURE)", without having to modify the application--if that's something you can't or don't want to do. Maybe this would help? Lee -
| Ingo Molnar | [announce] "kill the Big Kernel Lock (BKL)" tree |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Emmanuel Florac | RAID-1 performance under 2.4 and 2.6 |
| Con Kolivas | Re: -mm merge plans for 2.6.23 |
git: | |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| David Miller | [GIT]: Networking |
| Eric W. Biederman | Re: 2.6.24-rc3: find complains about /proc/net |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
