On Fri, Apr 01, 2011 at 10:17:56PM +0900, KOSAKI Motohiro wrote: > > > But, I agree that now we have to concern slightly large VM change parhaps > > > (or parhaps not). Ok, it's good opportunity to fill out some thing. > > > Historically, Linux MM has "free memory are waste memory" policy, and It > > > worked completely fine. But now we have a few exceptions. > > > > > > 1) RT, embedded and finance systems. They really hope to avoid reclaim > > > latency (ie avoid foreground reclaim completely) and they can accept > > > to make slightly much free pages before memory shortage. > > > > In general we need a mechanism to ensure we can avoid reclaim during > > critical sections of application. So some way to give some hints to the > > machine to free up lots of memory (/proc/sys/vm/dropcaches is far too > > drastic) may be useful. > > Exactly. > I've heard multiple times this request from finance people. And I've also > heared the same request from bullet train control software people recently. Well, that's enough to make me avoid Japanese trains in future. If your critical control system has problems with memory reclaim interfering with it's operation, then you are doing something very, very wrong. If you have a need to avoid memory allocation latency during specific critical sections then the critical section needs to: a) have all it's memory preallocated and mlock()d in advance b) avoid doing anything that requires memory to be allocated. These are basic design rules for time-sensitive applications. Fundamentally, if you just switch off memory reclaim to avoid the latencies involved with direct memory reclaim, then all you'll get instead is ENOMEM because there's no memory available and none will be reclaimed. That's even more fatal for the system than doing reclaim. IMO, you should tell the people requesting stuff like this to architect their critical sections according to best practices. Hacking the VM to try to work around badly designed applications is a sure recipe for disaster... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
