From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751195AbdAYCNm (ORCPT ); Tue, 24 Jan 2017 21:13:42 -0500 Received: from mail-pg0-f67.google.com ([74.125.83.67]:34950 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751113AbdAYCNl (ORCPT ); Tue, 24 Jan 2017 21:13:41 -0500 Subject: Re: [PATCH RFC 0/3] optimize kswapd when it does reclaim for hugepage To: Michal Hocko References: <1485244144-13487-1-git-send-email-hejianet@gmail.com> <20170124164646.GA30832@dhcp22.suse.cz> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Naoya Horiguchi , Mike Kravetz , "Aneesh Kumar K.V" , Gerald Schaefer , zhong jiang , "Kirill A. Shutemov" , Vaishali Thakkar , Johannes Weiner , Mel Gorman , Vlastimil Babka , Minchan Kim , Rik van Riel From: hejianet Message-ID: <666bf83b-5eac-6db8-b5da-b10b05ea05a4@gmail.com> Date: Wed, 25 Jan 2017 10:13:22 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170124164646.GA30832@dhcp22.suse.cz> 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 Hi Michal Thanks for the comments, I will resend the patch as per your comment after my 2 weeks vacation. B.R. Jia On 25/01/2017 12:46 AM, Michal Hocko wrote: > On Tue 24-01-17 15:49:01, Jia He wrote: >> If there is a server with uneven numa memory layout: >> available: 7 nodes (0-6) >> node 0 cpus: 0 1 2 3 4 5 6 7 >> node 0 size: 6603 MB >> node 0 free: 91 MB >> node 1 cpus: >> node 1 size: 12527 MB >> node 1 free: 157 MB >> node 2 cpus: >> node 2 size: 15087 MB >> node 2 free: 189 MB >> node 3 cpus: >> node 3 size: 16111 MB >> node 3 free: 205 MB >> node 4 cpus: 8 9 10 11 12 13 14 15 >> node 4 size: 24815 MB >> node 4 free: 310 MB >> node 5 cpus: >> node 5 size: 4095 MB >> node 5 free: 61 MB >> node 6 cpus: >> node 6 size: 22750 MB >> node 6 free: 283 MB >> node distances: >> node 0 1 2 3 4 5 6 >> 0: 10 20 40 40 40 40 40 >> 1: 20 10 40 40 40 40 40 >> 2: 40 40 10 20 40 40 40 >> 3: 40 40 20 10 40 40 40 >> 4: 40 40 40 40 10 20 40 >> 5: 40 40 40 40 20 10 40 >> 6: 40 40 40 40 40 40 10 >> >> In this case node 5 has less memory and we will alloc the hugepages >> from these nodes one by one after we trigger >> echo 4000 > /proc/sys/vm/nr_hugepages >> >> Then the kswapd5 will take 100% cpu for a long time. This is a livelock >> issue in kswapd. This patch set fixes it. > > It would be really helpful to describe what is the issue and whether it > is specific to the configuration above. Also a highlevel overview of the > fix and why it is the right approach would be appreciated. > >> The 3rd patch improves the kswapd's bad performance significantly. > > Numbers? > >> Jia He (3): >> mm/hugetlb: split alloc_fresh_huge_page_node into fast and slow path >> mm, vmscan: limit kswapd loop if no progress is made >> mm, vmscan: correct prepare_kswapd_sleep return value >> >> mm/hugetlb.c | 9 +++++++++ >> mm/vmscan.c | 28 ++++++++++++++++++++++++---- >> 2 files changed, 33 insertions(+), 4 deletions(-) >> >> -- >> 2.5.5 >> >