From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752404AbcDKGqG (ORCPT ); Mon, 11 Apr 2016 02:46:06 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:33792 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752183AbcDKGqD (ORCPT ); Mon, 11 Apr 2016 02:46:03 -0400 From: Michal Hocko To: Andrew Morton Cc: Mel Gorman , Rik van Riel , Vlastimil Babka , Johannes Weiner , , LKML Subject: [PATCH 0/2] oom detection rework followups Date: Mon, 11 Apr 2016 08:45:49 +0200 Message-Id: <1460357151-25554-1-git-send-email-mhocko@kernel.org> X-Mailer: git-send-email 2.8.0.rc3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, while playing with hugetlb test case described in [1] on a swapless system I managed to get my machine in an endless look inside the allocator. At first I found out the reclaim vs. compaction interaction doesn't work quite well. See patch2 for more details but it still bothered me why did_some_progress didn't break out of the loop. After some more debugging it turned out that it is compaction_ready used in the reclaim path which has been broken for quite some time. That's where patch1 came in and which is something to apply regardless the rest of the series. I was thinking whether to mark it for stable but cannot decide one way or the other. I think the fix is obvious but I am not so sure about all the potential side effects. A wrong compaction_ready decision would cause do_try_to_free_pages to break out early rather than dropping the reclaim priority and spending more time scanning LRUs. I have hard time to think about how good/bad this might be considering the compaction might decide to defer or just to do something useful between reclaim rounds. While patch 1 solved the issue I was seeing I still think that patch 2 is reasonable as well. It had fixed the issue as well but it is not really needed (at least for the above mentioned load) right now. On the other hand I like how it resembles the reclaim retry logic and puts some bound to when it make some sense to retry. So in short patch 1 should go regardless the oom detection rework which might take some time to settle down (assuming I haven't missed something and the fix is really correct), and patch 2 would be good to go on top of the current series. --- [1] http://lkml.kernel.org/r/1459855533-4600-12-git-send-email-mhocko@kernel.org