From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751922AbdIEIyl (ORCPT ); Tue, 5 Sep 2017 04:54:41 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:33227 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751345AbdIEIyh (ORCPT ); Tue, 5 Sep 2017 04:54:37 -0400 Subject: Re: [PATCH 2/2] mm, memory_hotplug: remove timeout from __offline_memory To: Michal Hocko , Anshuman Khandual References: <20170904082148.23131-1-mhocko@kernel.org> <20170904082148.23131-3-mhocko@kernel.org> <59AD15B6.7080304@huawei.com> <20170904090114.mrjxipvucieadxa6@dhcp22.suse.cz> <59AD174B.4020807@huawei.com> <20170904091505.xffd7orldpwlmrlx@dhcp22.suse.cz> <20170905072310.6iuui7h7rwrrnxdy@dhcp22.suse.cz> Cc: Xishi Qiu , Andrew Morton , KAMEZAWA Hiroyuki , Reza Arbab , Yasuaki Ishimatsu , Igor Mammedov , Vitaly Kuznetsov , linux-mm@kvack.org, LKML From: Anshuman Khandual Date: Tue, 5 Sep 2017 14:24:26 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170905072310.6iuui7h7rwrrnxdy@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable x-cbid: 17090508-0040-0000-0000-000003531DE5 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17090508-0041-0000-0000-00000CD130A4 Message-Id: <9a43dffa-0e0a-ed53-63a2-677cd162a1a7@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-09-05_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709050137 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/05/2017 12:53 PM, Michal Hocko wrote: > On Tue 05-09-17 11:16:57, Anshuman Khandual wrote: >> On 09/04/2017 02:45 PM, Michal Hocko wrote: >>> On Mon 04-09-17 17:05:15, Xishi Qiu wrote: >>>> On 2017/9/4 17:01, Michal Hocko wrote: >>>> >>>>> On Mon 04-09-17 16:58:30, Xishi Qiu wrote: >>>>>> On 2017/9/4 16:21, Michal Hocko wrote: >>>>>> >>>>>>> From: Michal Hocko >>>>>>> >>>>>>> We have a hardcoded 120s timeout after which the memory offline fails >>>>>>> basically since the hot remove has been introduced. This is essentially >>>>>>> a policy implemented in the kernel. Moreover there is no way to adjust >>>>>>> the timeout and so we are sometimes facing memory offline failures if >>>>>>> the system is under a heavy memory pressure or very intensive CPU >>>>>>> workload on large machines. >>>>>>> >>>>>>> It is not very clear what purpose the timeout actually serves. The >>>>>>> offline operation is interruptible by a signal so if userspace wants >>>>>> Hi Michal, >>>>>> >>>>>> If the user know what he should do if migration for a long time, >>>>>> it is OK, but I don't think all the users know this operation >>>>>> (e.g. ctrl + c) and the affect. >>>>> How is this operation any different from other potentially long >>>>> interruptible syscalls? >>>>> >>>> Hi Michal, >>>> >>>> I means the user should stop it by himself if migration always retry in endless. >>> If the memory is migrateable then the migration should finish >>> eventually. It can take some time but it shouldn't be an endless loop. >> >> But what if some how the temporary condition (page removed from the PCP >> LRU list and has not been freed yet to the buddy) happens again and again. > > How would that happen? We have all pages in the range MIGRATE_ISOLATE so > no pages will get reallocated and we know that there are no unmigratable > pages in the range. So we only should have temporary failures for > migration. If that is not the case then we have a bug somewhere. Right. > >> I understand we have schedule() and yield() to make sure that the context >> does not hold the CPU for ever but it can take theoretically very long >> time if not endless to finish. In that case sending signal to the user > > I guess you meant to say signal from the user space... Yes. > >> space process who initiated the offline request is the only way to stop >> this retry loop. I think this is still a better approach than the 120 >> second timeout which was kind of arbitrary. > > Yeah the context is interruptible so if the operation takes unbearably > too long then a watchdog can be setup trivially and to the user defined > value. There is a good reason we do not add hardocded timeouts to the > kernel. > Right. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f69.google.com (mail-pg0-f69.google.com [74.125.83.69]) by kanga.kvack.org (Postfix) with ESMTP id 8E1F228039D for ; Tue, 5 Sep 2017 04:54:40 -0400 (EDT) Received: by mail-pg0-f69.google.com with SMTP id m9so6358846pgd.2 for ; Tue, 05 Sep 2017 01:54:40 -0700 (PDT) Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com. [148.163.156.1]) by mx.google.com with ESMTPS id f30si8242plj.230.2017.09.05.01.54.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 01:54:39 -0700 (PDT) Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v858s4Bn048360 for ; Tue, 5 Sep 2017 04:54:39 -0400 Received: from e23smtp04.au.ibm.com (e23smtp04.au.ibm.com [202.81.31.146]) by mx0a-001b2d01.pphosted.com with ESMTP id 2csnv1srf7-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 05 Sep 2017 04:54:38 -0400 Received: from localhost by e23smtp04.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 5 Sep 2017 18:54:35 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay06.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v858sXWG41680922 for ; Tue, 5 Sep 2017 18:54:33 +1000 Received: from d23av01.au.ibm.com (localhost [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id v858sWfu022093 for ; Tue, 5 Sep 2017 18:54:32 +1000 Subject: Re: [PATCH 2/2] mm, memory_hotplug: remove timeout from __offline_memory References: <20170904082148.23131-1-mhocko@kernel.org> <20170904082148.23131-3-mhocko@kernel.org> <59AD15B6.7080304@huawei.com> <20170904090114.mrjxipvucieadxa6@dhcp22.suse.cz> <59AD174B.4020807@huawei.com> <20170904091505.xffd7orldpwlmrlx@dhcp22.suse.cz> <20170905072310.6iuui7h7rwrrnxdy@dhcp22.suse.cz> From: Anshuman Khandual Date: Tue, 5 Sep 2017 14:24:26 +0530 MIME-Version: 1.0 In-Reply-To: <20170905072310.6iuui7h7rwrrnxdy@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Message-Id: <9a43dffa-0e0a-ed53-63a2-677cd162a1a7@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko , Anshuman Khandual Cc: Xishi Qiu , Andrew Morton , KAMEZAWA Hiroyuki , Reza Arbab , Yasuaki Ishimatsu , Igor Mammedov , Vitaly Kuznetsov , linux-mm@kvack.org, LKML On 09/05/2017 12:53 PM, Michal Hocko wrote: > On Tue 05-09-17 11:16:57, Anshuman Khandual wrote: >> On 09/04/2017 02:45 PM, Michal Hocko wrote: >>> On Mon 04-09-17 17:05:15, Xishi Qiu wrote: >>>> On 2017/9/4 17:01, Michal Hocko wrote: >>>> >>>>> On Mon 04-09-17 16:58:30, Xishi Qiu wrote: >>>>>> On 2017/9/4 16:21, Michal Hocko wrote: >>>>>> >>>>>>> From: Michal Hocko >>>>>>> >>>>>>> We have a hardcoded 120s timeout after which the memory offline fails >>>>>>> basically since the hot remove has been introduced. This is essentially >>>>>>> a policy implemented in the kernel. Moreover there is no way to adjust >>>>>>> the timeout and so we are sometimes facing memory offline failures if >>>>>>> the system is under a heavy memory pressure or very intensive CPU >>>>>>> workload on large machines. >>>>>>> >>>>>>> It is not very clear what purpose the timeout actually serves. The >>>>>>> offline operation is interruptible by a signal so if userspace wants >>>>>> Hi Michal, >>>>>> >>>>>> If the user know what he should do if migration for a long time, >>>>>> it is OK, but I don't think all the users know this operation >>>>>> (e.g. ctrl + c) and the affect. >>>>> How is this operation any different from other potentially long >>>>> interruptible syscalls? >>>>> >>>> Hi Michal, >>>> >>>> I means the user should stop it by himself if migration always retry in endless. >>> If the memory is migrateable then the migration should finish >>> eventually. It can take some time but it shouldn't be an endless loop. >> >> But what if some how the temporary condition (page removed from the PCP >> LRU list and has not been freed yet to the buddy) happens again and again. > > How would that happen? We have all pages in the range MIGRATE_ISOLATE so > no pages will get reallocated and we know that there are no unmigratable > pages in the range. So we only should have temporary failures for > migration. If that is not the case then we have a bug somewhere. Right. > >> I understand we have schedule() and yield() to make sure that the context >> does not hold the CPU for ever but it can take theoretically very long >> time if not endless to finish. In that case sending signal to the user > > I guess you meant to say signal from the user space... Yes. > >> space process who initiated the offline request is the only way to stop >> this retry loop. I think this is still a better approach than the 120 >> second timeout which was kind of arbitrary. > > Yeah the context is interruptible so if the operation takes unbearably > too long then a watchdog can be setup trivially and to the user defined > value. There is a good reason we do not add hardocded timeouts to the > kernel. > Right. -- 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