On Thu 23-02-17 14:31:51, Vinayak Menon wrote: > > On 2/22/2017 4:13 PM, Michal Hocko wrote: [...] > > - the changelog doesn't mention that the test case basically benefits > > from as many lmk interventions as possible. Does this represent a real > > life workload? If not is there any real life workload which would > > benefit from the new behavior. > > The use case does not actually benefit from as many lmk interventions > as possible. Because it has to also take care of maximizing the number > of applications sustained. exactly and that is why I am questioning a more pessimistic events. LMK is a disruptive action so reporting critical actions too early can have negative impact. > IMHO Android using a vmpressure based user > space lowmemorykiller is a real life workload. But the lowmemorykiller > killer example was just to show the difference in vmpressure events > between 2 kernel versions. Any workload which uses vmpressure would > be something similar ? It would take an action by killing tasks, or > releasing some buffers etc as I understand. The patch was actually > meant to fix the addition of noise to vmpressure by adding reclaimed > without accounting the cost and the lmk example was just to indicate > the difference in vmpressure events. OK, it seems I have to repeat myself again. So what is the advantage of getting more pessimistic events and potentially fire disruptive actions sooner while we could still reclaim slab? Who is going to benefit from this except from the initial test case which, we agreed, is artificial? Why does the "noise" even matter? I am sorry but this whole change smells like "let's fix the test case" rather than "let's think what the real life use cases will benefit from" to me. As I've said I will not block this change because the cost model is so fuzzy that one way or another there will always be somebody complaining about it... So please, at least, make sure that somebody hunting a vmpressure misbehavior know why this has been changed! If this really is a test case motivated change then I would encourage you to withdraw this patch and instead try to think how to make the vmpressure more robust. -- Michal Hocko SUSE Labs -- 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>
