From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753030AbcEERZ0 (ORCPT ); Thu, 5 May 2016 13:25:26 -0400 Received: from mga02.intel.com ([134.134.136.20]:15737 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750803AbcEERZZ convert rfc822-to-8bit (ORCPT ); Thu, 5 May 2016 13:25:25 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,582,1455004800"; d="scan'208";a="799686439" From: "Odzioba, Lukasz" To: Michal Hocko CC: "Hansen, Dave" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "Shutemov, Kirill" , "Anaczkowski, Lukasz" Subject: RE: mm: pages are not freed from lru_add_pvecs after process termination Thread-Topic: mm: pages are not freed from lru_add_pvecs after process termination Thread-Index: AdGgo2TVXttFnfzXSCKoCVtWFlAf9///+AIAgAFnVQCABi40AP/8X4QQgAdEuoCAALQegP//TQwQ Date: Thu, 5 May 2016 17:25:07 +0000 Message-ID: References: <5720F2A8.6070406@intel.com> <20160428143710.GC31496@dhcp22.suse.cz> <20160502130006.GD25265@dhcp22.suse.cz> <20160504203643.GI21490@dhcp22.suse.cz> <20160505072122.GA4386@dhcp22.suse.cz> In-Reply-To: <20160505072122.GA4386@dhcp22.suse.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjMyMGNiZTgtMzRlMS00NDlhLTg4YWQtOWQ3ZTc5YWFiNjJjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNS45LjYuNiIsIlRydXN0ZWRMYWJlbEhhc2giOiJzbGp5cnVXNE0rMWxNTG5zRUZ5WXlSanpCOStjdkZcL3NKK3plaVlTdkw5Yz0ifQ== x-ctpclassification: CTP_PUBLIC x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 05-05-16 09:21:00, Michal Hocko wrote: > OK, it wasn't that tricky afterall. Maybe I have missed something but > the following should work. Or maybe the async nature of flushing turns > out to be just impractical and unreliable and we will end up skipping > THP (or all compound pages) for pcp LRU add cache. Let's see... Initially this issue was found on RH's 3.10.x kernel, but now I am using 4.6-rc6. In overall it does help and under heavy load it is slightly better than the second patch. Unfortunately I am still able to hit 10-20% oom kills with it - (went down from 30-50%) partially due to earlier vmstat_update call - it went up to 25-25% with this patch below: diff --git a/mm/page_alloc.c b/mm/page_alloc.c index b4359f8..7a5ab0d 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3264,17 +3264,17 @@ retry: if (!is_thp_gfp_mask(gfp_mask) || (current->flags & PF_KTHREAD)) migration_mode = MIGRATE_SYNC_LIGHT; - if(!vmstat_updated) { - vmstat_updated = true; - kick_vmstat_update(); - } - /* Try direct reclaim and then allocating */ page = __alloc_pages_direct_reclaim(gfp_mask, order, alloc_flags, ac, &did_some_progress); if (page) goto got_pg; + if(!vmstat_updated) { + vmstat_updated = true; + kick_vmstat_update(); + } I don't quite see an uninvasive way to make sure that we drain all pvecs before failing allocation and doing it asynchronously will race allocations anyway - I guess. Thanks, Lukas