Messages in this thread | | | Subject | Re: speeding up swapoff | From | Daniel Drake <> | Date | Thu, 30 Aug 2007 11:05:16 -0400 |
| |
On Thu, 2007-08-30 at 11:36 +0100, Hugh Dickins wrote: > Regarding Daniel's use of swapoff: it's a very heavy sledgehammer > for cracking that nut, I strongly agree with those who have pointed > him to mlock and mlockall instead.
There are some issues with us using mlockall. Admittedly, most/all of them are not the kernels problem (but a fast swapoff would be a good workaround):
We're using python 2.4, so mlock() itself isn't really an option (we don't realistically have access to the address regions hidden behind the language). mlockall() is a possibility, but the fact that all allocations above a particular limit will fail would potentially cause us problems given that it's hard to control python's memory usage for a long-running application.
Additionally, choosing that limit is hard given that we have this real-time and non-real-time processing balance, plus an interactive python-based application that runs all the time (which is the thing we would be locking). python 2.4 never returns memory to the OS, so at whatever point the memory usage of the application peaks, all that memory remains locked permanently.
In addition we have the non-real-time processing task which does benefit from having more memory available, so in that case, we would want it to swap out parts of the application. I guess we could ask the application to do munlockall() here, but things start getting scary and overcomplicated at this point...
So, our arguments against mlockall() are not strong, but you can see why fast swapoff would be mighty convenient.
Thanks for all the info so far. It does sound like my earlier idea wouldn't be any faster in the general case due to excess disk seeking. Oh well...
-- Daniel Drake Brontes Technologies, A 3M Company http://www.brontes3d.com/opensource
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |