From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f200.google.com (mail-qk0-f200.google.com [209.85.220.200]) by kanga.kvack.org (Postfix) with ESMTP id 91AB06B027F for ; Mon, 26 Sep 2016 04:48:18 -0400 (EDT) Received: by mail-qk0-f200.google.com with SMTP id m184so180557240qkb.1 for ; Mon, 26 Sep 2016 01:48:18 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com. [119.145.14.65]) by mx.google.com with ESMTPS id g8si13820498qka.164.2016.09.26.01.48.16 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 26 Sep 2016 01:48:18 -0700 (PDT) Message-ID: <57E8E0BD.2070603@huawei.com> Date: Mon, 26 Sep 2016 16:47:57 +0800 From: Xishi Qiu MIME-Version: 1.0 Subject: [RFC] mm: a question about high-order check in __zone_watermark_ok() Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Mel Gorman , Michal Hocko , Johannes Weiner , Vlastimil Babka Cc: LKML , Linux MM , Yisheng Xie commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 (mm, page_alloc: only enforce watermarks for order-0 allocations) rewrite the high-order check in __zone_watermark_ok(), but I think it quietly fix a bug. Please see the following. Before this patch, the high-order check is this: __zone_watermark_ok() ... for (o = 0; o < order; o++) { /* At the next order, this order's pages become unavailable */ free_pages -= z->free_area[o].nr_free << o; /* Require fewer higher order pages to be free */ min >>= 1; if (free_pages <= min) return false; } ... If we have cma memory, and we alloc a high-order movable page, then it's right. But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), and there are a lot of high-order cma pages, but little high-order unmovable pages, the it is still return *true*, but we will alloc *failed* finally, because we cannot fallback from migrate_unmovable to migrate_cma, right? Also if we doing __alloc_pages_slowpath(), the compact will not work, because __zone_watermark_ok() always return true, and it lead to alloc a high-order unmovable page failed, then do direct reclaim. Thanks, Xishi Qiu -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f71.google.com (mail-wm0-f71.google.com [74.125.82.71]) by kanga.kvack.org (Postfix) with ESMTP id A75BB280273 for ; Mon, 26 Sep 2016 04:52:47 -0400 (EDT) Received: by mail-wm0-f71.google.com with SMTP id b130so76518546wmc.2 for ; Mon, 26 Sep 2016 01:52:47 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id d1si18568884wjf.185.2016.09.26.01.52.46 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 26 Sep 2016 01:52:46 -0700 (PDT) Subject: Re: [RFC] mm: a question about high-order check in __zone_watermark_ok() References: <57E8E0BD.2070603@huawei.com> From: Vlastimil Babka Message-ID: <8cb02c0b-0825-d180-8ce3-dce6e584fc48@suse.cz> Date: Mon, 26 Sep 2016 10:52:42 +0200 MIME-Version: 1.0 In-Reply-To: <57E8E0BD.2070603@huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Xishi Qiu , Mel Gorman , Michal Hocko , Johannes Weiner Cc: LKML , Linux MM , Yisheng Xie , Joonsoo Kim [+CC Joonsoo Kim] On 09/26/2016 10:47 AM, Xishi Qiu wrote: > commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 > (mm, page_alloc: only enforce watermarks for order-0 allocations) > rewrite the high-order check in __zone_watermark_ok(), but I think it > quietly fix a bug. Please see the following. > > Before this patch, the high-order check is this: > __zone_watermark_ok() > ... > for (o = 0; o < order; o++) { > /* At the next order, this order's pages become unavailable */ > free_pages -= z->free_area[o].nr_free << o; > > /* Require fewer higher order pages to be free */ > min >>= 1; > > if (free_pages <= min) > return false; > } > ... > > If we have cma memory, and we alloc a high-order movable page, then it's right. > > But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), > and there are a lot of high-order cma pages, but little high-order unmovable > pages, the it is still return *true*, but we will alloc *failed* finally, because > we cannot fallback from migrate_unmovable to migrate_cma, right? Yeah I think this limitation was known to CMA people. > Also if we doing __alloc_pages_slowpath(), the compact will not work, because > __zone_watermark_ok() always return true, and it lead to alloc a high-order > unmovable page failed, then do direct reclaim. I guess that can happen as well. > Thanks, > Xishi Qiu > -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id 4366F280273 for ; Mon, 26 Sep 2016 04:58:53 -0400 (EDT) Received: by mail-wm0-f70.google.com with SMTP id b130so76678657wmc.2 for ; Mon, 26 Sep 2016 01:58:53 -0700 (PDT) Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com. [74.125.82.67]) by mx.google.com with ESMTPS id z21si7644330wmc.56.2016.09.26.01.58.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Sep 2016 01:58:52 -0700 (PDT) Received: by mail-wm0-f67.google.com with SMTP id w84so13002432wmg.0 for ; Mon, 26 Sep 2016 01:58:52 -0700 (PDT) Date: Mon, 26 Sep 2016 10:58:50 +0200 From: Michal Hocko Subject: Re: [RFC] mm: a question about high-order check in __zone_watermark_ok() Message-ID: <20160926085850.GB28550@dhcp22.suse.cz> References: <57E8E0BD.2070603@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57E8E0BD.2070603@huawei.com> Sender: owner-linux-mm@kvack.org List-ID: To: Xishi Qiu Cc: Mel Gorman , Johannes Weiner , Vlastimil Babka , LKML , Linux MM , Yisheng Xie On Mon 26-09-16 16:47:57, Xishi Qiu wrote: > commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 > (mm, page_alloc: only enforce watermarks for order-0 allocations) > rewrite the high-order check in __zone_watermark_ok(), but I think it > quietly fix a bug. Please see the following. > > Before this patch, the high-order check is this: > __zone_watermark_ok() > ... > for (o = 0; o < order; o++) { > /* At the next order, this order's pages become unavailable */ > free_pages -= z->free_area[o].nr_free << o; > > /* Require fewer higher order pages to be free */ > min >>= 1; > > if (free_pages <= min) > return false; > } > ... > > If we have cma memory, and we alloc a high-order movable page, then it's right. > > But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), > and there are a lot of high-order cma pages, but little high-order unmovable > pages, the it is still return *true*, but we will alloc *failed* finally, because > we cannot fallback from migrate_unmovable to migrate_cma, right? AFAIR CMA wmark check was always tricky and the above commit has made the situation at least a bit more clear. Anyway IIRC #ifdef CONFIG_CMA /* If allocation can't use CMA areas don't use free CMA pages */ if (!(alloc_flags & ALLOC_CMA)) free_cma = zone_page_state(z, NR_FREE_CMA_PAGES); #endif if (free_pages - free_cma <= min + z->lowmem_reserve[classzone_idx]) return false; should reduce the prioblem because a lot of CMA pages should just get us below the wmark + reserve boundary. -- Michal Hocko SUSE Labs -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f71.google.com (mail-oi0-f71.google.com [209.85.218.71]) by kanga.kvack.org (Postfix) with ESMTP id DCFF6280273 for ; Mon, 26 Sep 2016 05:21:04 -0400 (EDT) Received: by mail-oi0-f71.google.com with SMTP id t83so501316713oie.0 for ; Mon, 26 Sep 2016 02:21:04 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com. [58.251.152.64]) by mx.google.com with ESMTP id z52si7022385otz.12.2016.09.26.02.21.02 for ; Mon, 26 Sep 2016 02:21:04 -0700 (PDT) Message-ID: <57E8E786.8030703@huawei.com> Date: Mon, 26 Sep 2016 17:16:54 +0800 From: Xishi Qiu MIME-Version: 1.0 Subject: Re: [RFC] mm: a question about high-order check in __zone_watermark_ok() References: <57E8E0BD.2070603@huawei.com> <20160926085850.GB28550@dhcp22.suse.cz> In-Reply-To: <20160926085850.GB28550@dhcp22.suse.cz> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Mel Gorman , Johannes Weiner , Vlastimil Babka , LKML , Linux MM , Yisheng Xie On 2016/9/26 16:58, Michal Hocko wrote: > On Mon 26-09-16 16:47:57, Xishi Qiu wrote: >> commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 >> (mm, page_alloc: only enforce watermarks for order-0 allocations) >> rewrite the high-order check in __zone_watermark_ok(), but I think it >> quietly fix a bug. Please see the following. >> >> Before this patch, the high-order check is this: >> __zone_watermark_ok() >> ... >> for (o = 0; o < order; o++) { >> /* At the next order, this order's pages become unavailable */ >> free_pages -= z->free_area[o].nr_free << o; >> >> /* Require fewer higher order pages to be free */ >> min >>= 1; >> >> if (free_pages <= min) >> return false; >> } >> ... >> >> If we have cma memory, and we alloc a high-order movable page, then it's right. >> >> But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), >> and there are a lot of high-order cma pages, but little high-order unmovable >> pages, the it is still return *true*, but we will alloc *failed* finally, because >> we cannot fallback from migrate_unmovable to migrate_cma, right? > > AFAIR CMA wmark check was always tricky and the above commit has made > the situation at least a bit more clear. Anyway IIRC > > #ifdef CONFIG_CMA > /* If allocation can't use CMA areas don't use free CMA pages */ > if (!(alloc_flags & ALLOC_CMA)) > free_cma = zone_page_state(z, NR_FREE_CMA_PAGES); > #endif > > if (free_pages - free_cma <= min + z->lowmem_reserve[classzone_idx]) > return false; > > should reduce the prioblem because a lot of CMA pages should just get us > below the wmark + reserve boundary. Hi Michal, If we have many high-order cma pages, and the left pages (unmovable/movable/reclaimable) are also enough, but they are fragment, then it will triger the problem. If we alloc a high-order unmovable page, water mark check return *true*, but we will alloc *failed*, right? Thanks, Xishi Qiu -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f71.google.com (mail-wm0-f71.google.com [74.125.82.71]) by kanga.kvack.org (Postfix) with ESMTP id 84FDE280273 for ; Mon, 26 Sep 2016 05:43:36 -0400 (EDT) Received: by mail-wm0-f71.google.com with SMTP id l138so77994395wmg.3 for ; Mon, 26 Sep 2016 02:43:36 -0700 (PDT) Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com. [74.125.82.66]) by mx.google.com with ESMTPS id gg6si18689904wjd.136.2016.09.26.02.43.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Sep 2016 02:43:35 -0700 (PDT) Received: by mail-wm0-f66.google.com with SMTP id w84so13183521wmg.0 for ; Mon, 26 Sep 2016 02:43:35 -0700 (PDT) Date: Mon, 26 Sep 2016 11:43:33 +0200 From: Michal Hocko Subject: Re: [RFC] mm: a question about high-order check in __zone_watermark_ok() Message-ID: <20160926094333.GD28550@dhcp22.suse.cz> References: <57E8E0BD.2070603@huawei.com> <20160926085850.GB28550@dhcp22.suse.cz> <57E8E786.8030703@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57E8E786.8030703@huawei.com> Sender: owner-linux-mm@kvack.org List-ID: To: Xishi Qiu Cc: Mel Gorman , Johannes Weiner , Vlastimil Babka , LKML , Linux MM , Yisheng Xie On Mon 26-09-16 17:16:54, Xishi Qiu wrote: > On 2016/9/26 16:58, Michal Hocko wrote: > > > On Mon 26-09-16 16:47:57, Xishi Qiu wrote: > >> commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 > >> (mm, page_alloc: only enforce watermarks for order-0 allocations) > >> rewrite the high-order check in __zone_watermark_ok(), but I think it > >> quietly fix a bug. Please see the following. > >> > >> Before this patch, the high-order check is this: > >> __zone_watermark_ok() > >> ... > >> for (o = 0; o < order; o++) { > >> /* At the next order, this order's pages become unavailable */ > >> free_pages -= z->free_area[o].nr_free << o; > >> > >> /* Require fewer higher order pages to be free */ > >> min >>= 1; > >> > >> if (free_pages <= min) > >> return false; > >> } > >> ... > >> > >> If we have cma memory, and we alloc a high-order movable page, then it's right. > >> > >> But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), > >> and there are a lot of high-order cma pages, but little high-order unmovable > >> pages, the it is still return *true*, but we will alloc *failed* finally, because > >> we cannot fallback from migrate_unmovable to migrate_cma, right? > > > > AFAIR CMA wmark check was always tricky and the above commit has made > > the situation at least a bit more clear. Anyway IIRC > > > > #ifdef CONFIG_CMA > > /* If allocation can't use CMA areas don't use free CMA pages */ > > if (!(alloc_flags & ALLOC_CMA)) > > free_cma = zone_page_state(z, NR_FREE_CMA_PAGES); > > #endif > > > > if (free_pages - free_cma <= min + z->lowmem_reserve[classzone_idx]) > > return false; > > > > should reduce the prioblem because a lot of CMA pages should just get us > > below the wmark + reserve boundary. > > Hi Michal, > > If we have many high-order cma pages, and the left pages (unmovable/movable/reclaimable) > are also enough, but they are fragment, then it will triger the problem. > If we alloc a high-order unmovable page, water mark check return *true*, but we > will alloc *failed*, right? As Vlastimil has written. There were known issues with the wmark checks and high order requests. -- Michal Hocko SUSE Labs -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f70.google.com (mail-it0-f70.google.com [209.85.214.70]) by kanga.kvack.org (Postfix) with ESMTP id AAB106B0275 for ; Mon, 26 Sep 2016 06:19:01 -0400 (EDT) Received: by mail-it0-f70.google.com with SMTP id e20so202061546itc.3 for ; Mon, 26 Sep 2016 03:19:01 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com. [58.251.152.64]) by mx.google.com with ESMTP id b72si6612033itb.34.2016.09.26.03.18.59 for ; Mon, 26 Sep 2016 03:19:01 -0700 (PDT) Message-ID: <57E8F5CE.908@huawei.com> Date: Mon, 26 Sep 2016 18:17:50 +0800 From: Xishi Qiu MIME-Version: 1.0 Subject: Re: [RFC] mm: a question about high-order check in __zone_watermark_ok() References: <57E8E0BD.2070603@huawei.com> <20160926085850.GB28550@dhcp22.suse.cz> <57E8E786.8030703@huawei.com> <20160926094333.GD28550@dhcp22.suse.cz> In-Reply-To: <20160926094333.GD28550@dhcp22.suse.cz> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Mel Gorman , Johannes Weiner , Vlastimil Babka , LKML , Linux MM , Yisheng Xie On 2016/9/26 17:43, Michal Hocko wrote: > On Mon 26-09-16 17:16:54, Xishi Qiu wrote: >> On 2016/9/26 16:58, Michal Hocko wrote: >> >>> On Mon 26-09-16 16:47:57, Xishi Qiu wrote: >>>> commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 >>>> (mm, page_alloc: only enforce watermarks for order-0 allocations) >>>> rewrite the high-order check in __zone_watermark_ok(), but I think it >>>> quietly fix a bug. Please see the following. >>>> >>>> Before this patch, the high-order check is this: >>>> __zone_watermark_ok() >>>> ... >>>> for (o = 0; o < order; o++) { >>>> /* At the next order, this order's pages become unavailable */ >>>> free_pages -= z->free_area[o].nr_free << o; >>>> >>>> /* Require fewer higher order pages to be free */ >>>> min >>= 1; >>>> >>>> if (free_pages <= min) >>>> return false; >>>> } >>>> ... >>>> >>>> If we have cma memory, and we alloc a high-order movable page, then it's right. >>>> >>>> But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), >>>> and there are a lot of high-order cma pages, but little high-order unmovable >>>> pages, the it is still return *true*, but we will alloc *failed* finally, because >>>> we cannot fallback from migrate_unmovable to migrate_cma, right? >>> >>> AFAIR CMA wmark check was always tricky and the above commit has made >>> the situation at least a bit more clear. Anyway IIRC >>> >>> #ifdef CONFIG_CMA >>> /* If allocation can't use CMA areas don't use free CMA pages */ >>> if (!(alloc_flags & ALLOC_CMA)) >>> free_cma = zone_page_state(z, NR_FREE_CMA_PAGES); >>> #endif >>> >>> if (free_pages - free_cma <= min + z->lowmem_reserve[classzone_idx]) >>> return false; >>> >>> should reduce the prioblem because a lot of CMA pages should just get us >>> below the wmark + reserve boundary. >> >> Hi Michal, >> >> If we have many high-order cma pages, and the left pages (unmovable/movable/reclaimable) >> are also enough, but they are fragment, then it will triger the problem. >> If we alloc a high-order unmovable page, water mark check return *true*, but we >> will alloc *failed*, right? > > As Vlastimil has written. There were known issues with the wmark checks > and high order requests. Shall we backport to stable? Thanks, Xishi Qiu -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id 05B32280274 for ; Mon, 26 Sep 2016 07:02:34 -0400 (EDT) Received: by mail-wm0-f70.google.com with SMTP id l138so80050401wmg.3 for ; Mon, 26 Sep 2016 04:02:33 -0700 (PDT) Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com. [74.125.82.68]) by mx.google.com with ESMTPS id i2si18943736wjd.159.2016.09.26.04.02.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Sep 2016 04:02:32 -0700 (PDT) Received: by mail-wm0-f68.google.com with SMTP id 133so13521960wmq.2 for ; Mon, 26 Sep 2016 04:02:32 -0700 (PDT) Date: Mon, 26 Sep 2016 13:02:31 +0200 From: Michal Hocko Subject: Re: [RFC] mm: a question about high-order check in __zone_watermark_ok() Message-ID: <20160926110231.GE28550@dhcp22.suse.cz> References: <57E8E0BD.2070603@huawei.com> <20160926085850.GB28550@dhcp22.suse.cz> <57E8E786.8030703@huawei.com> <20160926094333.GD28550@dhcp22.suse.cz> <57E8F5CE.908@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57E8F5CE.908@huawei.com> Sender: owner-linux-mm@kvack.org List-ID: To: Xishi Qiu Cc: Mel Gorman , Johannes Weiner , Vlastimil Babka , LKML , Linux MM , Yisheng Xie On Mon 26-09-16 18:17:50, Xishi Qiu wrote: > On 2016/9/26 17:43, Michal Hocko wrote: > > > On Mon 26-09-16 17:16:54, Xishi Qiu wrote: > >> On 2016/9/26 16:58, Michal Hocko wrote: > >> > >>> On Mon 26-09-16 16:47:57, Xishi Qiu wrote: > >>>> commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 > >>>> (mm, page_alloc: only enforce watermarks for order-0 allocations) > >>>> rewrite the high-order check in __zone_watermark_ok(), but I think it > >>>> quietly fix a bug. Please see the following. > >>>> > >>>> Before this patch, the high-order check is this: > >>>> __zone_watermark_ok() > >>>> ... > >>>> for (o = 0; o < order; o++) { > >>>> /* At the next order, this order's pages become unavailable */ > >>>> free_pages -= z->free_area[o].nr_free << o; > >>>> > >>>> /* Require fewer higher order pages to be free */ > >>>> min >>= 1; > >>>> > >>>> if (free_pages <= min) > >>>> return false; > >>>> } > >>>> ... > >>>> > >>>> If we have cma memory, and we alloc a high-order movable page, then it's right. > >>>> > >>>> But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), > >>>> and there are a lot of high-order cma pages, but little high-order unmovable > >>>> pages, the it is still return *true*, but we will alloc *failed* finally, because > >>>> we cannot fallback from migrate_unmovable to migrate_cma, right? > >>> > >>> AFAIR CMA wmark check was always tricky and the above commit has made > >>> the situation at least a bit more clear. Anyway IIRC > >>> > >>> #ifdef CONFIG_CMA > >>> /* If allocation can't use CMA areas don't use free CMA pages */ > >>> if (!(alloc_flags & ALLOC_CMA)) > >>> free_cma = zone_page_state(z, NR_FREE_CMA_PAGES); > >>> #endif > >>> > >>> if (free_pages - free_cma <= min + z->lowmem_reserve[classzone_idx]) > >>> return false; > >>> > >>> should reduce the prioblem because a lot of CMA pages should just get us > >>> below the wmark + reserve boundary. > >> > >> Hi Michal, > >> > >> If we have many high-order cma pages, and the left pages (unmovable/movable/reclaimable) > >> are also enough, but they are fragment, then it will triger the problem. > >> If we alloc a high-order unmovable page, water mark check return *true*, but we > >> will alloc *failed*, right? > > > > As Vlastimil has written. There were known issues with the wmark checks > > and high order requests. > > Shall we backport to stable? I dunno, it was a part of a larger series with high atomic reserves and changes which sound a bit intrusive for the stable kernel. Considering that CMA was known to be problematic and there are still some issues left I do not think this is worth the trouble/risk. -- Michal Hocko SUSE Labs -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f197.google.com (mail-io0-f197.google.com [209.85.223.197]) by kanga.kvack.org (Postfix) with ESMTP id 93CEA280251 for ; Wed, 28 Sep 2016 01:43:39 -0400 (EDT) Received: by mail-io0-f197.google.com with SMTP id 82so87907238ioh.1 for ; Tue, 27 Sep 2016 22:43:39 -0700 (PDT) Received: from lgeamrelo12.lge.com (LGEAMRELO12.lge.com. [156.147.23.52]) by mx.google.com with ESMTP id l39si8106199ioi.184.2016.09.27.22.43.38 for ; Tue, 27 Sep 2016 22:43:39 -0700 (PDT) Date: Wed, 28 Sep 2016 14:52:03 +0900 From: Joonsoo Kim Subject: Re: [RFC] mm: a question about high-order check in __zone_watermark_ok() Message-ID: <20160928055203.GE22706@js1304-P5Q-DELUXE> References: <57E8E0BD.2070603@huawei.com> <20160926085850.GB28550@dhcp22.suse.cz> <57E8E786.8030703@huawei.com> <20160926094333.GD28550@dhcp22.suse.cz> <57E8F5CE.908@huawei.com> <20160926110231.GE28550@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160926110231.GE28550@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Xishi Qiu , Mel Gorman , Johannes Weiner , Vlastimil Babka , LKML , Linux MM , Yisheng Xie On Mon, Sep 26, 2016 at 01:02:31PM +0200, Michal Hocko wrote: > On Mon 26-09-16 18:17:50, Xishi Qiu wrote: > > On 2016/9/26 17:43, Michal Hocko wrote: > > > > > On Mon 26-09-16 17:16:54, Xishi Qiu wrote: > > >> On 2016/9/26 16:58, Michal Hocko wrote: > > >> > > >>> On Mon 26-09-16 16:47:57, Xishi Qiu wrote: > > >>>> commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 > > >>>> (mm, page_alloc: only enforce watermarks for order-0 allocations) > > >>>> rewrite the high-order check in __zone_watermark_ok(), but I think it > > >>>> quietly fix a bug. Please see the following. > > >>>> > > >>>> Before this patch, the high-order check is this: > > >>>> __zone_watermark_ok() > > >>>> ... > > >>>> for (o = 0; o < order; o++) { > > >>>> /* At the next order, this order's pages become unavailable */ > > >>>> free_pages -= z->free_area[o].nr_free << o; > > >>>> > > >>>> /* Require fewer higher order pages to be free */ > > >>>> min >>= 1; > > >>>> > > >>>> if (free_pages <= min) > > >>>> return false; > > >>>> } > > >>>> ... > > >>>> > > >>>> If we have cma memory, and we alloc a high-order movable page, then it's right. > > >>>> > > >>>> But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), > > >>>> and there are a lot of high-order cma pages, but little high-order unmovable > > >>>> pages, the it is still return *true*, but we will alloc *failed* finally, because > > >>>> we cannot fallback from migrate_unmovable to migrate_cma, right? > > >>> > > >>> AFAIR CMA wmark check was always tricky and the above commit has made > > >>> the situation at least a bit more clear. Anyway IIRC > > >>> > > >>> #ifdef CONFIG_CMA > > >>> /* If allocation can't use CMA areas don't use free CMA pages */ > > >>> if (!(alloc_flags & ALLOC_CMA)) > > >>> free_cma = zone_page_state(z, NR_FREE_CMA_PAGES); > > >>> #endif > > >>> > > >>> if (free_pages - free_cma <= min + z->lowmem_reserve[classzone_idx]) > > >>> return false; > > >>> > > >>> should reduce the prioblem because a lot of CMA pages should just get us > > >>> below the wmark + reserve boundary. > > >> > > >> Hi Michal, > > >> > > >> If we have many high-order cma pages, and the left pages (unmovable/movable/reclaimable) > > >> are also enough, but they are fragment, then it will triger the problem. > > >> If we alloc a high-order unmovable page, water mark check return *true*, but we > > >> will alloc *failed*, right? > > > > > > As Vlastimil has written. There were known issues with the wmark checks > > > and high order requests. > > > > Shall we backport to stable? > > I dunno, it was a part of a larger series with high atomic reserves and > changes which sound a bit intrusive for the stable kernel. Considering > that CMA was known to be problematic and there are still some issues > left I do not think this is worth the trouble/risk. CMA problem is known one. I mentioned it on my ZONE_CMA series v1 but removed due to Mel's high atomic reserve series. That series is rather large and has some problems so I think that it is not suitable for stable tree. Thanks. -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f200.google.com (mail-io0-f200.google.com [209.85.223.200]) by kanga.kvack.org (Postfix) with ESMTP id 059676B0266 for ; Wed, 28 Sep 2016 03:55:20 -0400 (EDT) Received: by mail-io0-f200.google.com with SMTP id 92so96891959iom.3 for ; Wed, 28 Sep 2016 00:55:20 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com. [119.145.14.66]) by mx.google.com with ESMTPS id x3si8652652itg.43.2016.09.28.00.55.02 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 28 Sep 2016 00:55:03 -0700 (PDT) Message-ID: <57EB7746.7030108@huawei.com> Date: Wed, 28 Sep 2016 15:54:46 +0800 From: Xishi Qiu MIME-Version: 1.0 Subject: Re: [RFC] mm: a question about high-order check in __zone_watermark_ok() References: <57E8E0BD.2070603@huawei.com> <20160926085850.GB28550@dhcp22.suse.cz> <57E8E786.8030703@huawei.com> <20160926094333.GD28550@dhcp22.suse.cz> <57E8F5CE.908@huawei.com> <20160926110231.GE28550@dhcp22.suse.cz> <20160928055203.GE22706@js1304-P5Q-DELUXE> In-Reply-To: <20160928055203.GE22706@js1304-P5Q-DELUXE> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Joonsoo Kim Cc: Michal Hocko , Mel Gorman , Johannes Weiner , Vlastimil Babka , LKML , Linux MM , Yisheng Xie On 2016/9/28 13:52, Joonsoo Kim wrote: > On Mon, Sep 26, 2016 at 01:02:31PM +0200, Michal Hocko wrote: >> On Mon 26-09-16 18:17:50, Xishi Qiu wrote: >>> On 2016/9/26 17:43, Michal Hocko wrote: >>> >>>> On Mon 26-09-16 17:16:54, Xishi Qiu wrote: >>>>> On 2016/9/26 16:58, Michal Hocko wrote: >>>>> >>>>>> On Mon 26-09-16 16:47:57, Xishi Qiu wrote: >>>>>>> commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 >>>>>>> (mm, page_alloc: only enforce watermarks for order-0 allocations) >>>>>>> rewrite the high-order check in __zone_watermark_ok(), but I think it >>>>>>> quietly fix a bug. Please see the following. >>>>>>> >>>>>>> Before this patch, the high-order check is this: >>>>>>> __zone_watermark_ok() >>>>>>> ... >>>>>>> for (o = 0; o < order; o++) { >>>>>>> /* At the next order, this order's pages become unavailable */ >>>>>>> free_pages -= z->free_area[o].nr_free << o; >>>>>>> >>>>>>> /* Require fewer higher order pages to be free */ >>>>>>> min >>= 1; >>>>>>> >>>>>>> if (free_pages <= min) >>>>>>> return false; >>>>>>> } >>>>>>> ... >>>>>>> >>>>>>> If we have cma memory, and we alloc a high-order movable page, then it's right. >>>>>>> >>>>>>> But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), >>>>>>> and there are a lot of high-order cma pages, but little high-order unmovable >>>>>>> pages, the it is still return *true*, but we will alloc *failed* finally, because >>>>>>> we cannot fallback from migrate_unmovable to migrate_cma, right? >>>>>> >>>>>> AFAIR CMA wmark check was always tricky and the above commit has made >>>>>> the situation at least a bit more clear. Anyway IIRC >>>>>> >>>>>> #ifdef CONFIG_CMA >>>>>> /* If allocation can't use CMA areas don't use free CMA pages */ >>>>>> if (!(alloc_flags & ALLOC_CMA)) >>>>>> free_cma = zone_page_state(z, NR_FREE_CMA_PAGES); >>>>>> #endif >>>>>> >>>>>> if (free_pages - free_cma <= min + z->lowmem_reserve[classzone_idx]) >>>>>> return false; >>>>>> >>>>>> should reduce the prioblem because a lot of CMA pages should just get us >>>>>> below the wmark + reserve boundary. >>>>> >>>>> Hi Michal, >>>>> >>>>> If we have many high-order cma pages, and the left pages (unmovable/movable/reclaimable) >>>>> are also enough, but they are fragment, then it will triger the problem. >>>>> If we alloc a high-order unmovable page, water mark check return *true*, but we >>>>> will alloc *failed*, right? >>>> >>>> As Vlastimil has written. There were known issues with the wmark checks >>>> and high order requests. >>> >>> Shall we backport to stable? >> >> I dunno, it was a part of a larger series with high atomic reserves and >> changes which sound a bit intrusive for the stable kernel. Considering >> that CMA was known to be problematic and there are still some issues >> left I do not think this is worth the trouble/risk. > > CMA problem is known one. I mentioned it on my ZONE_CMA series v1 but > removed due to Mel's high atomic reserve series. > > That series is rather large and has some problems so I think that it > is not suitable for stable tree. > > Thanks. > OK, I know, thank you very much. Thanks, Xishi Qiu > . > -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759598AbcIZIsY (ORCPT ); Mon, 26 Sep 2016 04:48:24 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:29945 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751202AbcIZIsX (ORCPT ); Mon, 26 Sep 2016 04:48:23 -0400 Message-ID: <57E8E0BD.2070603@huawei.com> Date: Mon, 26 Sep 2016 16:47:57 +0800 From: Xishi Qiu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mel Gorman , Michal Hocko , Johannes Weiner , Vlastimil Babka CC: LKML , Linux MM , Yisheng Xie Subject: [RFC] mm: a question about high-order check in __zone_watermark_ok() Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.25.179] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.57E8E0CC.0006,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 81be4c7533844305b355ca7a3dd497ab Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 (mm, page_alloc: only enforce watermarks for order-0 allocations) rewrite the high-order check in __zone_watermark_ok(), but I think it quietly fix a bug. Please see the following. Before this patch, the high-order check is this: __zone_watermark_ok() ... for (o = 0; o < order; o++) { /* At the next order, this order's pages become unavailable */ free_pages -= z->free_area[o].nr_free << o; /* Require fewer higher order pages to be free */ min >>= 1; if (free_pages <= min) return false; } ... If we have cma memory, and we alloc a high-order movable page, then it's right. But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), and there are a lot of high-order cma pages, but little high-order unmovable pages, the it is still return *true*, but we will alloc *failed* finally, because we cannot fallback from migrate_unmovable to migrate_cma, right? Also if we doing __alloc_pages_slowpath(), the compact will not work, because __zone_watermark_ok() always return true, and it lead to alloc a high-order unmovable page failed, then do direct reclaim. Thanks, Xishi Qiu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965693AbcIZIws (ORCPT ); Mon, 26 Sep 2016 04:52:48 -0400 Received: from mx2.suse.de ([195.135.220.15]:42373 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965343AbcIZIwr (ORCPT ); Mon, 26 Sep 2016 04:52:47 -0400 Subject: Re: [RFC] mm: a question about high-order check in __zone_watermark_ok() To: Xishi Qiu , Mel Gorman , Michal Hocko , Johannes Weiner References: <57E8E0BD.2070603@huawei.com> Cc: LKML , Linux MM , Yisheng Xie , Joonsoo Kim From: Vlastimil Babka Message-ID: <8cb02c0b-0825-d180-8ce3-dce6e584fc48@suse.cz> Date: Mon, 26 Sep 2016 10:52:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <57E8E0BD.2070603@huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [+CC Joonsoo Kim] On 09/26/2016 10:47 AM, Xishi Qiu wrote: > commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 > (mm, page_alloc: only enforce watermarks for order-0 allocations) > rewrite the high-order check in __zone_watermark_ok(), but I think it > quietly fix a bug. Please see the following. > > Before this patch, the high-order check is this: > __zone_watermark_ok() > ... > for (o = 0; o < order; o++) { > /* At the next order, this order's pages become unavailable */ > free_pages -= z->free_area[o].nr_free << o; > > /* Require fewer higher order pages to be free */ > min >>= 1; > > if (free_pages <= min) > return false; > } > ... > > If we have cma memory, and we alloc a high-order movable page, then it's right. > > But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), > and there are a lot of high-order cma pages, but little high-order unmovable > pages, the it is still return *true*, but we will alloc *failed* finally, because > we cannot fallback from migrate_unmovable to migrate_cma, right? Yeah I think this limitation was known to CMA people. > Also if we doing __alloc_pages_slowpath(), the compact will not work, because > __zone_watermark_ok() always return true, and it lead to alloc a high-order > unmovable page failed, then do direct reclaim. I guess that can happen as well. > Thanks, > Xishi Qiu > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935933AbcIZI6z (ORCPT ); Mon, 26 Sep 2016 04:58:55 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:34435 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933666AbcIZI6x (ORCPT ); Mon, 26 Sep 2016 04:58:53 -0400 Date: Mon, 26 Sep 2016 10:58:50 +0200 From: Michal Hocko To: Xishi Qiu Cc: Mel Gorman , Johannes Weiner , Vlastimil Babka , LKML , Linux MM , Yisheng Xie Subject: Re: [RFC] mm: a question about high-order check in __zone_watermark_ok() Message-ID: <20160926085850.GB28550@dhcp22.suse.cz> References: <57E8E0BD.2070603@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57E8E0BD.2070603@huawei.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 26-09-16 16:47:57, Xishi Qiu wrote: > commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 > (mm, page_alloc: only enforce watermarks for order-0 allocations) > rewrite the high-order check in __zone_watermark_ok(), but I think it > quietly fix a bug. Please see the following. > > Before this patch, the high-order check is this: > __zone_watermark_ok() > ... > for (o = 0; o < order; o++) { > /* At the next order, this order's pages become unavailable */ > free_pages -= z->free_area[o].nr_free << o; > > /* Require fewer higher order pages to be free */ > min >>= 1; > > if (free_pages <= min) > return false; > } > ... > > If we have cma memory, and we alloc a high-order movable page, then it's right. > > But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), > and there are a lot of high-order cma pages, but little high-order unmovable > pages, the it is still return *true*, but we will alloc *failed* finally, because > we cannot fallback from migrate_unmovable to migrate_cma, right? AFAIR CMA wmark check was always tricky and the above commit has made the situation at least a bit more clear. Anyway IIRC #ifdef CONFIG_CMA /* If allocation can't use CMA areas don't use free CMA pages */ if (!(alloc_flags & ALLOC_CMA)) free_cma = zone_page_state(z, NR_FREE_CMA_PAGES); #endif if (free_pages - free_cma <= min + z->lowmem_reserve[classzone_idx]) return false; should reduce the prioblem because a lot of CMA pages should just get us below the wmark + reserve boundary. -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937054AbcIZJRd (ORCPT ); Mon, 26 Sep 2016 05:17:33 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:19237 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932426AbcIZJRc (ORCPT ); Mon, 26 Sep 2016 05:17:32 -0400 Message-ID: <57E8E786.8030703@huawei.com> Date: Mon, 26 Sep 2016 17:16:54 +0800 From: Xishi Qiu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Michal Hocko CC: Mel Gorman , Johannes Weiner , Vlastimil Babka , LKML , Linux MM , Yisheng Xie Subject: Re: [RFC] mm: a question about high-order check in __zone_watermark_ok() References: <57E8E0BD.2070603@huawei.com> <20160926085850.GB28550@dhcp22.suse.cz> In-Reply-To: <20160926085850.GB28550@dhcp22.suse.cz> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.25.179] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.57E8E796.00BB,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9017d875a8d3d4d3af6021017f2b7202 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/9/26 16:58, Michal Hocko wrote: > On Mon 26-09-16 16:47:57, Xishi Qiu wrote: >> commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 >> (mm, page_alloc: only enforce watermarks for order-0 allocations) >> rewrite the high-order check in __zone_watermark_ok(), but I think it >> quietly fix a bug. Please see the following. >> >> Before this patch, the high-order check is this: >> __zone_watermark_ok() >> ... >> for (o = 0; o < order; o++) { >> /* At the next order, this order's pages become unavailable */ >> free_pages -= z->free_area[o].nr_free << o; >> >> /* Require fewer higher order pages to be free */ >> min >>= 1; >> >> if (free_pages <= min) >> return false; >> } >> ... >> >> If we have cma memory, and we alloc a high-order movable page, then it's right. >> >> But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), >> and there are a lot of high-order cma pages, but little high-order unmovable >> pages, the it is still return *true*, but we will alloc *failed* finally, because >> we cannot fallback from migrate_unmovable to migrate_cma, right? > > AFAIR CMA wmark check was always tricky and the above commit has made > the situation at least a bit more clear. Anyway IIRC > > #ifdef CONFIG_CMA > /* If allocation can't use CMA areas don't use free CMA pages */ > if (!(alloc_flags & ALLOC_CMA)) > free_cma = zone_page_state(z, NR_FREE_CMA_PAGES); > #endif > > if (free_pages - free_cma <= min + z->lowmem_reserve[classzone_idx]) > return false; > > should reduce the prioblem because a lot of CMA pages should just get us > below the wmark + reserve boundary. Hi Michal, If we have many high-order cma pages, and the left pages (unmovable/movable/reclaimable) are also enough, but they are fragment, then it will triger the problem. If we alloc a high-order unmovable page, water mark check return *true*, but we will alloc *failed*, right? Thanks, Xishi Qiu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965676AbcIZJnh (ORCPT ); Mon, 26 Sep 2016 05:43:37 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:35854 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751493AbcIZJng (ORCPT ); Mon, 26 Sep 2016 05:43:36 -0400 Date: Mon, 26 Sep 2016 11:43:33 +0200 From: Michal Hocko To: Xishi Qiu Cc: Mel Gorman , Johannes Weiner , Vlastimil Babka , LKML , Linux MM , Yisheng Xie Subject: Re: [RFC] mm: a question about high-order check in __zone_watermark_ok() Message-ID: <20160926094333.GD28550@dhcp22.suse.cz> References: <57E8E0BD.2070603@huawei.com> <20160926085850.GB28550@dhcp22.suse.cz> <57E8E786.8030703@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57E8E786.8030703@huawei.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 26-09-16 17:16:54, Xishi Qiu wrote: > On 2016/9/26 16:58, Michal Hocko wrote: > > > On Mon 26-09-16 16:47:57, Xishi Qiu wrote: > >> commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 > >> (mm, page_alloc: only enforce watermarks for order-0 allocations) > >> rewrite the high-order check in __zone_watermark_ok(), but I think it > >> quietly fix a bug. Please see the following. > >> > >> Before this patch, the high-order check is this: > >> __zone_watermark_ok() > >> ... > >> for (o = 0; o < order; o++) { > >> /* At the next order, this order's pages become unavailable */ > >> free_pages -= z->free_area[o].nr_free << o; > >> > >> /* Require fewer higher order pages to be free */ > >> min >>= 1; > >> > >> if (free_pages <= min) > >> return false; > >> } > >> ... > >> > >> If we have cma memory, and we alloc a high-order movable page, then it's right. > >> > >> But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), > >> and there are a lot of high-order cma pages, but little high-order unmovable > >> pages, the it is still return *true*, but we will alloc *failed* finally, because > >> we cannot fallback from migrate_unmovable to migrate_cma, right? > > > > AFAIR CMA wmark check was always tricky and the above commit has made > > the situation at least a bit more clear. Anyway IIRC > > > > #ifdef CONFIG_CMA > > /* If allocation can't use CMA areas don't use free CMA pages */ > > if (!(alloc_flags & ALLOC_CMA)) > > free_cma = zone_page_state(z, NR_FREE_CMA_PAGES); > > #endif > > > > if (free_pages - free_cma <= min + z->lowmem_reserve[classzone_idx]) > > return false; > > > > should reduce the prioblem because a lot of CMA pages should just get us > > below the wmark + reserve boundary. > > Hi Michal, > > If we have many high-order cma pages, and the left pages (unmovable/movable/reclaimable) > are also enough, but they are fragment, then it will triger the problem. > If we alloc a high-order unmovable page, water mark check return *true*, but we > will alloc *failed*, right? As Vlastimil has written. There were known issues with the wmark checks and high order requests. -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966532AbcIZKSi (ORCPT ); Mon, 26 Sep 2016 06:18:38 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:19183 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965050AbcIZKSa (ORCPT ); Mon, 26 Sep 2016 06:18:30 -0400 Message-ID: <57E8F5CE.908@huawei.com> Date: Mon, 26 Sep 2016 18:17:50 +0800 From: Xishi Qiu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Michal Hocko CC: Mel Gorman , Johannes Weiner , Vlastimil Babka , LKML , Linux MM , Yisheng Xie Subject: Re: [RFC] mm: a question about high-order check in __zone_watermark_ok() References: <57E8E0BD.2070603@huawei.com> <20160926085850.GB28550@dhcp22.suse.cz> <57E8E786.8030703@huawei.com> <20160926094333.GD28550@dhcp22.suse.cz> In-Reply-To: <20160926094333.GD28550@dhcp22.suse.cz> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.25.179] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57E8F5E6.0086,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9017d875a8d3d4d3af6021017f2b7202 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/9/26 17:43, Michal Hocko wrote: > On Mon 26-09-16 17:16:54, Xishi Qiu wrote: >> On 2016/9/26 16:58, Michal Hocko wrote: >> >>> On Mon 26-09-16 16:47:57, Xishi Qiu wrote: >>>> commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 >>>> (mm, page_alloc: only enforce watermarks for order-0 allocations) >>>> rewrite the high-order check in __zone_watermark_ok(), but I think it >>>> quietly fix a bug. Please see the following. >>>> >>>> Before this patch, the high-order check is this: >>>> __zone_watermark_ok() >>>> ... >>>> for (o = 0; o < order; o++) { >>>> /* At the next order, this order's pages become unavailable */ >>>> free_pages -= z->free_area[o].nr_free << o; >>>> >>>> /* Require fewer higher order pages to be free */ >>>> min >>= 1; >>>> >>>> if (free_pages <= min) >>>> return false; >>>> } >>>> ... >>>> >>>> If we have cma memory, and we alloc a high-order movable page, then it's right. >>>> >>>> But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), >>>> and there are a lot of high-order cma pages, but little high-order unmovable >>>> pages, the it is still return *true*, but we will alloc *failed* finally, because >>>> we cannot fallback from migrate_unmovable to migrate_cma, right? >>> >>> AFAIR CMA wmark check was always tricky and the above commit has made >>> the situation at least a bit more clear. Anyway IIRC >>> >>> #ifdef CONFIG_CMA >>> /* If allocation can't use CMA areas don't use free CMA pages */ >>> if (!(alloc_flags & ALLOC_CMA)) >>> free_cma = zone_page_state(z, NR_FREE_CMA_PAGES); >>> #endif >>> >>> if (free_pages - free_cma <= min + z->lowmem_reserve[classzone_idx]) >>> return false; >>> >>> should reduce the prioblem because a lot of CMA pages should just get us >>> below the wmark + reserve boundary. >> >> Hi Michal, >> >> If we have many high-order cma pages, and the left pages (unmovable/movable/reclaimable) >> are also enough, but they are fragment, then it will triger the problem. >> If we alloc a high-order unmovable page, water mark check return *true*, but we >> will alloc *failed*, right? > > As Vlastimil has written. There were known issues with the wmark checks > and high order requests. Shall we backport to stable? Thanks, Xishi Qiu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966472AbcIZLCf (ORCPT ); Mon, 26 Sep 2016 07:02:35 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:36371 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965095AbcIZLCd (ORCPT ); Mon, 26 Sep 2016 07:02:33 -0400 Date: Mon, 26 Sep 2016 13:02:31 +0200 From: Michal Hocko To: Xishi Qiu Cc: Mel Gorman , Johannes Weiner , Vlastimil Babka , LKML , Linux MM , Yisheng Xie Subject: Re: [RFC] mm: a question about high-order check in __zone_watermark_ok() Message-ID: <20160926110231.GE28550@dhcp22.suse.cz> References: <57E8E0BD.2070603@huawei.com> <20160926085850.GB28550@dhcp22.suse.cz> <57E8E786.8030703@huawei.com> <20160926094333.GD28550@dhcp22.suse.cz> <57E8F5CE.908@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57E8F5CE.908@huawei.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 26-09-16 18:17:50, Xishi Qiu wrote: > On 2016/9/26 17:43, Michal Hocko wrote: > > > On Mon 26-09-16 17:16:54, Xishi Qiu wrote: > >> On 2016/9/26 16:58, Michal Hocko wrote: > >> > >>> On Mon 26-09-16 16:47:57, Xishi Qiu wrote: > >>>> commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 > >>>> (mm, page_alloc: only enforce watermarks for order-0 allocations) > >>>> rewrite the high-order check in __zone_watermark_ok(), but I think it > >>>> quietly fix a bug. Please see the following. > >>>> > >>>> Before this patch, the high-order check is this: > >>>> __zone_watermark_ok() > >>>> ... > >>>> for (o = 0; o < order; o++) { > >>>> /* At the next order, this order's pages become unavailable */ > >>>> free_pages -= z->free_area[o].nr_free << o; > >>>> > >>>> /* Require fewer higher order pages to be free */ > >>>> min >>= 1; > >>>> > >>>> if (free_pages <= min) > >>>> return false; > >>>> } > >>>> ... > >>>> > >>>> If we have cma memory, and we alloc a high-order movable page, then it's right. > >>>> > >>>> But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), > >>>> and there are a lot of high-order cma pages, but little high-order unmovable > >>>> pages, the it is still return *true*, but we will alloc *failed* finally, because > >>>> we cannot fallback from migrate_unmovable to migrate_cma, right? > >>> > >>> AFAIR CMA wmark check was always tricky and the above commit has made > >>> the situation at least a bit more clear. Anyway IIRC > >>> > >>> #ifdef CONFIG_CMA > >>> /* If allocation can't use CMA areas don't use free CMA pages */ > >>> if (!(alloc_flags & ALLOC_CMA)) > >>> free_cma = zone_page_state(z, NR_FREE_CMA_PAGES); > >>> #endif > >>> > >>> if (free_pages - free_cma <= min + z->lowmem_reserve[classzone_idx]) > >>> return false; > >>> > >>> should reduce the prioblem because a lot of CMA pages should just get us > >>> below the wmark + reserve boundary. > >> > >> Hi Michal, > >> > >> If we have many high-order cma pages, and the left pages (unmovable/movable/reclaimable) > >> are also enough, but they are fragment, then it will triger the problem. > >> If we alloc a high-order unmovable page, water mark check return *true*, but we > >> will alloc *failed*, right? > > > > As Vlastimil has written. There were known issues with the wmark checks > > and high order requests. > > Shall we backport to stable? I dunno, it was a part of a larger series with high atomic reserves and changes which sound a bit intrusive for the stable kernel. Considering that CMA was known to be problematic and there are still some issues left I do not think this is worth the trouble/risk. -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752293AbcI1Fnt (ORCPT ); Wed, 28 Sep 2016 01:43:49 -0400 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:40232 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750970AbcI1Fnj (ORCPT ); Wed, 28 Sep 2016 01:43:39 -0400 X-Original-SENDERIP: 156.147.1.125 X-Original-MAILFROM: iamjoonsoo.kim@lge.com X-Original-SENDERIP: 10.177.222.138 X-Original-MAILFROM: iamjoonsoo.kim@lge.com Date: Wed, 28 Sep 2016 14:52:03 +0900 From: Joonsoo Kim To: Michal Hocko Cc: Xishi Qiu , Mel Gorman , Johannes Weiner , Vlastimil Babka , LKML , Linux MM , Yisheng Xie Subject: Re: [RFC] mm: a question about high-order check in __zone_watermark_ok() Message-ID: <20160928055203.GE22706@js1304-P5Q-DELUXE> References: <57E8E0BD.2070603@huawei.com> <20160926085850.GB28550@dhcp22.suse.cz> <57E8E786.8030703@huawei.com> <20160926094333.GD28550@dhcp22.suse.cz> <57E8F5CE.908@huawei.com> <20160926110231.GE28550@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160926110231.GE28550@dhcp22.suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 26, 2016 at 01:02:31PM +0200, Michal Hocko wrote: > On Mon 26-09-16 18:17:50, Xishi Qiu wrote: > > On 2016/9/26 17:43, Michal Hocko wrote: > > > > > On Mon 26-09-16 17:16:54, Xishi Qiu wrote: > > >> On 2016/9/26 16:58, Michal Hocko wrote: > > >> > > >>> On Mon 26-09-16 16:47:57, Xishi Qiu wrote: > > >>>> commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 > > >>>> (mm, page_alloc: only enforce watermarks for order-0 allocations) > > >>>> rewrite the high-order check in __zone_watermark_ok(), but I think it > > >>>> quietly fix a bug. Please see the following. > > >>>> > > >>>> Before this patch, the high-order check is this: > > >>>> __zone_watermark_ok() > > >>>> ... > > >>>> for (o = 0; o < order; o++) { > > >>>> /* At the next order, this order's pages become unavailable */ > > >>>> free_pages -= z->free_area[o].nr_free << o; > > >>>> > > >>>> /* Require fewer higher order pages to be free */ > > >>>> min >>= 1; > > >>>> > > >>>> if (free_pages <= min) > > >>>> return false; > > >>>> } > > >>>> ... > > >>>> > > >>>> If we have cma memory, and we alloc a high-order movable page, then it's right. > > >>>> > > >>>> But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), > > >>>> and there are a lot of high-order cma pages, but little high-order unmovable > > >>>> pages, the it is still return *true*, but we will alloc *failed* finally, because > > >>>> we cannot fallback from migrate_unmovable to migrate_cma, right? > > >>> > > >>> AFAIR CMA wmark check was always tricky and the above commit has made > > >>> the situation at least a bit more clear. Anyway IIRC > > >>> > > >>> #ifdef CONFIG_CMA > > >>> /* If allocation can't use CMA areas don't use free CMA pages */ > > >>> if (!(alloc_flags & ALLOC_CMA)) > > >>> free_cma = zone_page_state(z, NR_FREE_CMA_PAGES); > > >>> #endif > > >>> > > >>> if (free_pages - free_cma <= min + z->lowmem_reserve[classzone_idx]) > > >>> return false; > > >>> > > >>> should reduce the prioblem because a lot of CMA pages should just get us > > >>> below the wmark + reserve boundary. > > >> > > >> Hi Michal, > > >> > > >> If we have many high-order cma pages, and the left pages (unmovable/movable/reclaimable) > > >> are also enough, but they are fragment, then it will triger the problem. > > >> If we alloc a high-order unmovable page, water mark check return *true*, but we > > >> will alloc *failed*, right? > > > > > > As Vlastimil has written. There were known issues with the wmark checks > > > and high order requests. > > > > Shall we backport to stable? > > I dunno, it was a part of a larger series with high atomic reserves and > changes which sound a bit intrusive for the stable kernel. Considering > that CMA was known to be problematic and there are still some issues > left I do not think this is worth the trouble/risk. CMA problem is known one. I mentioned it on my ZONE_CMA series v1 but removed due to Mel's high atomic reserve series. That series is rather large and has some problems so I think that it is not suitable for stable tree. Thanks. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751736AbcI1HzQ (ORCPT ); Wed, 28 Sep 2016 03:55:16 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:55848 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751495AbcI1HzI (ORCPT ); Wed, 28 Sep 2016 03:55:08 -0400 Message-ID: <57EB7746.7030108@huawei.com> Date: Wed, 28 Sep 2016 15:54:46 +0800 From: Xishi Qiu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Joonsoo Kim CC: Michal Hocko , Mel Gorman , Johannes Weiner , Vlastimil Babka , LKML , "Linux MM" , Yisheng Xie Subject: Re: [RFC] mm: a question about high-order check in __zone_watermark_ok() References: <57E8E0BD.2070603@huawei.com> <20160926085850.GB28550@dhcp22.suse.cz> <57E8E786.8030703@huawei.com> <20160926094333.GD28550@dhcp22.suse.cz> <57E8F5CE.908@huawei.com> <20160926110231.GE28550@dhcp22.suse.cz> <20160928055203.GE22706@js1304-P5Q-DELUXE> In-Reply-To: <20160928055203.GE22706@js1304-P5Q-DELUXE> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.25.179] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.57EB7755.000C,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d8d83c9e79d8d21af67c098b5c5a6bc7 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/9/28 13:52, Joonsoo Kim wrote: > On Mon, Sep 26, 2016 at 01:02:31PM +0200, Michal Hocko wrote: >> On Mon 26-09-16 18:17:50, Xishi Qiu wrote: >>> On 2016/9/26 17:43, Michal Hocko wrote: >>> >>>> On Mon 26-09-16 17:16:54, Xishi Qiu wrote: >>>>> On 2016/9/26 16:58, Michal Hocko wrote: >>>>> >>>>>> On Mon 26-09-16 16:47:57, Xishi Qiu wrote: >>>>>>> commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 >>>>>>> (mm, page_alloc: only enforce watermarks for order-0 allocations) >>>>>>> rewrite the high-order check in __zone_watermark_ok(), but I think it >>>>>>> quietly fix a bug. Please see the following. >>>>>>> >>>>>>> Before this patch, the high-order check is this: >>>>>>> __zone_watermark_ok() >>>>>>> ... >>>>>>> for (o = 0; o < order; o++) { >>>>>>> /* At the next order, this order's pages become unavailable */ >>>>>>> free_pages -= z->free_area[o].nr_free << o; >>>>>>> >>>>>>> /* Require fewer higher order pages to be free */ >>>>>>> min >>= 1; >>>>>>> >>>>>>> if (free_pages <= min) >>>>>>> return false; >>>>>>> } >>>>>>> ... >>>>>>> >>>>>>> If we have cma memory, and we alloc a high-order movable page, then it's right. >>>>>>> >>>>>>> But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()), >>>>>>> and there are a lot of high-order cma pages, but little high-order unmovable >>>>>>> pages, the it is still return *true*, but we will alloc *failed* finally, because >>>>>>> we cannot fallback from migrate_unmovable to migrate_cma, right? >>>>>> >>>>>> AFAIR CMA wmark check was always tricky and the above commit has made >>>>>> the situation at least a bit more clear. Anyway IIRC >>>>>> >>>>>> #ifdef CONFIG_CMA >>>>>> /* If allocation can't use CMA areas don't use free CMA pages */ >>>>>> if (!(alloc_flags & ALLOC_CMA)) >>>>>> free_cma = zone_page_state(z, NR_FREE_CMA_PAGES); >>>>>> #endif >>>>>> >>>>>> if (free_pages - free_cma <= min + z->lowmem_reserve[classzone_idx]) >>>>>> return false; >>>>>> >>>>>> should reduce the prioblem because a lot of CMA pages should just get us >>>>>> below the wmark + reserve boundary. >>>>> >>>>> Hi Michal, >>>>> >>>>> If we have many high-order cma pages, and the left pages (unmovable/movable/reclaimable) >>>>> are also enough, but they are fragment, then it will triger the problem. >>>>> If we alloc a high-order unmovable page, water mark check return *true*, but we >>>>> will alloc *failed*, right? >>>> >>>> As Vlastimil has written. There were known issues with the wmark checks >>>> and high order requests. >>> >>> Shall we backport to stable? >> >> I dunno, it was a part of a larger series with high atomic reserves and >> changes which sound a bit intrusive for the stable kernel. Considering >> that CMA was known to be problematic and there are still some issues >> left I do not think this is worth the trouble/risk. > > CMA problem is known one. I mentioned it on my ZONE_CMA series v1 but > removed due to Mel's high atomic reserve series. > > That series is rather large and has some problems so I think that it > is not suitable for stable tree. > > Thanks. > OK, I know, thank you very much. Thanks, Xishi Qiu > . >