On Thu, Jun 27, 2013 at 06:11:03PM +0200, Michal Hocko wrote: > > If we send critical but there isn't big memory pressure, maybe > > critical handler would kill some process and the result is that > > killing another process unnecessary. That's really thing we should > > avoid. Yes, so that is why I actually want to ack the patch... It might be not an ideal solution, but to me it seems like a good for the time being. (Actually I should have done that check myself.) > > > The THP case made sense because nr_scanned is in LRU elements units > > > while nr_reclaimed is in page units which are different so nr_reclaim > > > might be higher than nr_scanned (so nr_taken would be more approapriate > > > for vmpressure). > > > > In case of THP, 512 page is equal to vmpressure_win so if we change > > nr_scanned with nr_taken, it could easily make vmpressure notifier > > Wasn't 512 selected for vmpressure_win exactly for this reason? Nope. The current vmpressure_win was selected kind of arbitrary, i.e. it worked good for most of my test cases. > Shouldn't we rather fix that assumption? If there is any assumption (which I had not in my mind :), then we definitely should do that, since vmpressure_win is going to be machine-size dependant. Thanks, Anton -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>