On Fri, Mar 19, 2010 at 03:31:27PM +0900, KOSAKI Motohiro wrote: > > Viewpoint 1. Unnecessary IO > > > > isolate_pages() for lumpy reclaim frequently grab very young page. it is often > > still dirty. then, pageout() is called much. > > > > Unfortunately, page size grained io is _very_ inefficient. it can makes lots disk > > seek and kill disk io bandwidth. > > > > > > Viewpoint 2. Unevictable pages > > > > isolate_pages() for lumpy reclaim can pick up unevictable page. it is obviously > > undroppable. so if the zone have plenty mlocked pages (it is not rare case on > > server use case), lumpy reclaim can become very useless. > > > > > > Viewpoint 3. GFP_ATOMIC allocation failure > > > > Obviously lumpy reclaim can't help GFP_ATOMIC issue. > > > > > > Viewpoint 4. reclaim latency > > > > reclaim latency directly affect page allocation latency. so if lumpy reclaim with > > much pageout io is slow (often it is), it affect page allocation latency and can > > reduce end user experience. > > Viewpoint 5. end user surprising > > lumpy reclaim can makes swap-out even though the system have lots free > memory. end users very surprised it and they can think it is bug. > > Also, this swap activity easyly confuse that an administrator decide when > install more memory into the system. > Compaction in this case is a lot less surprising. If there is enough free memory, compaction will trigger automatically without any reclaim. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>