Re: [PATCH v2] mm: vmscan: abort proactive reclaim early when freezing for suspend

[Michal Hocko <mhocko@suse.com>]

On Tue 14-07-26 14:23:50, Michal Hocko wrote:
> On Tue 14-07-26 17:00:37, Richard Chang wrote:
[...]
> > On the other hand, the freezer timeout/suspend failure is a genuine
> > bug currently impacting Android devices in the field. The proposed
> > patch safely addresses this immediate issue by leveraging the
> > pre-existing -EINTR exit path in user_proactive_reclaim(). Could we
> > focus on the current patch and open a separate discussion for a more
> > ideal, long-term design regarding freezer invisibility as a follow-up?
> 
> I am not insisting both to be addressed in the same patch. But building
> more on top of a broken behavior is not healthy either.
> In the current state this should be as easy as turning signal_pending
> into fatal_signal_pending and try_to_freeze at the pro-active reclaim
> entry point which should be safe from the freezer POV.

Something like the following on top of your early break from reclaim
patch. Maybe there is a better way. Freezer has always been quite
confusing to me but this should work AFAICT.

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 35c3bb15ae96..3795734b3a22 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -7909,9 +7909,15 @@ int user_proactive_reclaim(char *buf,
 		unsigned long batch_size = (nr_to_reclaim - nr_reclaimed) / 4;
 		unsigned long reclaimed;
 
-		if (signal_pending(current))
+		if (fatal_signal_pending(current))
 			return -EINTR;
 
+		/*
+		 * Make sure this potentially costly operation doesn't block
+		 * freezer for too long.
+		 */
+		try_to_freeze();
+
 		/*
 		 * This is the final attempt, drain percpu lru caches in the
 		 * hope of introducing more evictable pages.
-- 
Michal Hocko
SUSE Labs