On Sun, Apr 03, 2011 at 06:32:16PM +0900, KOSAKI Motohiro wrote: > > 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. > > [...] > > 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. > > You have two level oversight. > > Firstly, *ALL* RT application need to cooperate applications, kernel, > and other various system level daemons. That's no specific issue of > this topic. OK, *IF* RT application run egoistic, a system may hang > up easily even routh mere simple busy loop, yes. But, Who want to do so? Sure - that's RT-101. I think I have a good understanding of these principles after spending 7 years of my life working on wide-area distributed real-time control systems (think city-scale water and electricity supply). > Secondly, You misparsed "avoid direct reclaim" paragraph. We don't talk > about "avoid direct reclaim even if system memory is no enough", We talk > about "avoid direct reclaim by preparing before". I don't think I misparsed it. I am addressing the "avoid direct reclaim by preparing before" principle directly. The problem with it is that just enalrging the free memory pool doesn't guarantee future allocation success when there are other concurrent allocations occurring. IOWs, if you don't _reserve_ the free memory for the critical area in advance then there is no guarantee it will be available when needed by the critical section. A simple example: the radix tree node preallocation code to guarantee inserts succeed while holding a spinlock. If just relying on free memory was sufficient, then GFP_ATOMIC allocations are all that is necessary. However, even that isn't sufficient as even the GFP_ATOMIC reserved pool can be exhausted by other concurrent GFP_ATOMIC allocations. Hence preallocation is required before entering the critical section to guarantee success in all cases. And to state the obvious: doing allocation before the critical section will trigger reclaim if necessary so there is no need to have the application trigger reclaim. 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
