From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752251AbdIMMTX (ORCPT ); Wed, 13 Sep 2017 08:19:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:34614 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751153AbdIMMTW (ORCPT ); Wed, 13 Sep 2017 08:19:22 -0400 Subject: Re: [PATCH 1/2] mm, memory_hotplug: do not fail offlining too early To: Michal Hocko Cc: Andrew Morton , KAMEZAWA Hiroyuki , Reza Arbab , Yasuaki Ishimatsu , qiuxishi@huawei.com, Igor Mammedov , Vitaly Kuznetsov , linux-mm@kvack.org, LKML References: <20170904082148.23131-1-mhocko@kernel.org> <20170904082148.23131-2-mhocko@kernel.org> <20170911081714.4zc33r7wlj2nnbho@dhcp22.suse.cz> <9fad7246-c634-18bb-78f9-b95376c009da@suse.cz> <20170913121001.k3a5tkvunmncc5uj@dhcp22.suse.cz> <20170913121433.yjzloaf6g447zeq2@dhcp22.suse.cz> From: Vlastimil Babka Message-ID: <25ffda93-0c0d-28b4-bd0b-7fc9df7d678a@suse.cz> Date: Wed, 13 Sep 2017 14:19:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170913121433.yjzloaf6g447zeq2@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/13/2017 02:14 PM, Michal Hocko wrote: >>>> Do you think that the changelog should be more clear about this? >>> >>> It certainly wouldn't hurt :) >> >> So what do you think about the following wording: > > Ups, wrong patch > > > From 8639496a834b4a7c24972ec23b17e50f0d6a304c Mon Sep 17 00:00:00 2001 > From: Michal Hocko > Date: Mon, 14 Aug 2017 10:46:12 +0200 > Subject: [PATCH 1/2] mm, memory_hotplug: do not fail offlining too early > > Memory offlining can fail just too eagerly under a heavy memory pressure. > > [ 5410.336792] page:ffffea22a646bd00 count:255 mapcount:252 mapping:ffff88ff926c9f38 index:0x3 > [ 5410.336809] flags: 0x9855fe40010048(uptodate|active|mappedtodisk) > [ 5410.336811] page dumped because: isolation failed > [ 5410.336813] page->mem_cgroup:ffff8801cd662000 > [ 5420.655030] memory offlining [mem 0x18b580000000-0x18b5ffffffff] failed > > Isolation has failed here because the page is not on LRU. Most probably > because it was on the pcp LRU cache or it has been removed from the LRU > already but it hasn't been freed yet. In both cases the page doesn't look > non-migrable so retrying more makes sense. > > __offline_pages seems rather cluttered when it comes to the retry > logic. We have 5 retries at maximum and a timeout. We could argue > whether the timeout makes sense but failing just because of a race when > somebody isoltes a page from LRU or puts it on a pcp LRU lists is just > wrong. It only takes it to race with a process which unmaps some pages > and remove them from the LRU list and we can fail the whole offline > because of something that is a temporary condition and actually not > harmful for the offline. > > Please note that unmovable pages should be already excluded during > start_isolate_page_range. We could argue that has_unmovable_pages is > racy and MIGRATE_MOVABLE check doesn't provide any hard guarantee either > but kernel zones (aka < ZONE_MOVABLE) will very likely detect unmovable > pages in most cases and movable zone shouldn't contain unmovable pages > at all. Some of those pages might be pinned but not for ever because > that would be a bug on its own. In any case the context is still > interruptible and so the userspace can easily bail out when the > operation takes too long. This is certainly better behavior than a > hardcoded retry loop which is racy. > > Fix this by removing the max retry count and only rely on the timeout > resp. interruption by a signal from the userspace. Also retry rather > than fail when check_pages_isolated sees some !free pages because those > could be a result of the race as well. > > Signed-off-by: Michal Hocko Yeah, that's better, thanks. Acked-by: Vlastimil Babka From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f71.google.com (mail-pg0-f71.google.com [74.125.83.71]) by kanga.kvack.org (Postfix) with ESMTP id 22FCA6B0038 for ; Wed, 13 Sep 2017 08:19:24 -0400 (EDT) Received: by mail-pg0-f71.google.com with SMTP id 6so85585pgh.0 for ; Wed, 13 Sep 2017 05:19:24 -0700 (PDT) Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id q13si9125880pgn.679.2017.09.13.05.19.22 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 13 Sep 2017 05:19:22 -0700 (PDT) Subject: Re: [PATCH 1/2] mm, memory_hotplug: do not fail offlining too early References: <20170904082148.23131-1-mhocko@kernel.org> <20170904082148.23131-2-mhocko@kernel.org> <20170911081714.4zc33r7wlj2nnbho@dhcp22.suse.cz> <9fad7246-c634-18bb-78f9-b95376c009da@suse.cz> <20170913121001.k3a5tkvunmncc5uj@dhcp22.suse.cz> <20170913121433.yjzloaf6g447zeq2@dhcp22.suse.cz> From: Vlastimil Babka Message-ID: <25ffda93-0c0d-28b4-bd0b-7fc9df7d678a@suse.cz> Date: Wed, 13 Sep 2017 14:19:19 +0200 MIME-Version: 1.0 In-Reply-To: <20170913121433.yjzloaf6g447zeq2@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Andrew Morton , KAMEZAWA Hiroyuki , Reza Arbab , Yasuaki Ishimatsu , qiuxishi@huawei.com, Igor Mammedov , Vitaly Kuznetsov , linux-mm@kvack.org, LKML On 09/13/2017 02:14 PM, Michal Hocko wrote: >>>> Do you think that the changelog should be more clear about this? >>> >>> It certainly wouldn't hurt :) >> >> So what do you think about the following wording: > > Ups, wrong patch > > > From 8639496a834b4a7c24972ec23b17e50f0d6a304c Mon Sep 17 00:00:00 2001 > From: Michal Hocko > Date: Mon, 14 Aug 2017 10:46:12 +0200 > Subject: [PATCH 1/2] mm, memory_hotplug: do not fail offlining too early > > Memory offlining can fail just too eagerly under a heavy memory pressure. > > [ 5410.336792] page:ffffea22a646bd00 count:255 mapcount:252 mapping:ffff88ff926c9f38 index:0x3 > [ 5410.336809] flags: 0x9855fe40010048(uptodate|active|mappedtodisk) > [ 5410.336811] page dumped because: isolation failed > [ 5410.336813] page->mem_cgroup:ffff8801cd662000 > [ 5420.655030] memory offlining [mem 0x18b580000000-0x18b5ffffffff] failed > > Isolation has failed here because the page is not on LRU. Most probably > because it was on the pcp LRU cache or it has been removed from the LRU > already but it hasn't been freed yet. In both cases the page doesn't look > non-migrable so retrying more makes sense. > > __offline_pages seems rather cluttered when it comes to the retry > logic. We have 5 retries at maximum and a timeout. We could argue > whether the timeout makes sense but failing just because of a race when > somebody isoltes a page from LRU or puts it on a pcp LRU lists is just > wrong. It only takes it to race with a process which unmaps some pages > and remove them from the LRU list and we can fail the whole offline > because of something that is a temporary condition and actually not > harmful for the offline. > > Please note that unmovable pages should be already excluded during > start_isolate_page_range. We could argue that has_unmovable_pages is > racy and MIGRATE_MOVABLE check doesn't provide any hard guarantee either > but kernel zones (aka < ZONE_MOVABLE) will very likely detect unmovable > pages in most cases and movable zone shouldn't contain unmovable pages > at all. Some of those pages might be pinned but not for ever because > that would be a bug on its own. In any case the context is still > interruptible and so the userspace can easily bail out when the > operation takes too long. This is certainly better behavior than a > hardcoded retry loop which is racy. > > Fix this by removing the max retry count and only rely on the timeout > resp. interruption by a signal from the userspace. Also retry rather > than fail when check_pages_isolated sees some !free pages because those > could be a result of the race as well. > > Signed-off-by: Michal Hocko Yeah, that's better, thanks. Acked-by: Vlastimil Babka -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org