Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932440AbdHWP7L (ORCPT ); Wed, 23 Aug 2017 11:59:11 -0400 Received: from mga03.intel.com ([134.134.136.65]:63440 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932300AbdHWP7I (ORCPT ); Wed, 23 Aug 2017 11:59:08 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,417,1498546800"; d="scan'208";a="1006891002" Subject: Re: [PATCH 1/2] sched/wait: Break up long wake list walk To: "Liang, Kan" , Linus Torvalds Cc: Mel Gorman , Mel Gorman , "Kirill A. Shutemov" , Peter Zijlstra , Ingo Molnar , Andi Kleen , Andrew Morton , Johannes Weiner , Jan Kara , linux-mm , Linux Kernel Mailing List References: <37D7C6CF3E00A74B8858931C1DB2F077537879BB@SHSMSX103.ccr.corp.intel.com> <20170818144622.oabozle26hasg5yo@techsingularity.net> <37D7C6CF3E00A74B8858931C1DB2F07753787AE4@SHSMSX103.ccr.corp.intel.com> <20170818185455.qol3st2nynfa47yc@techsingularity.net> <20170821183234.kzennaaw2zt2rbwz@techsingularity.net> <37D7C6CF3E00A74B8858931C1DB2F07753788B58@SHSMSX103.ccr.corp.intel.com> <37D7C6CF3E00A74B8858931C1DB2F0775378A24A@SHSMSX103.ccr.corp.intel.com> <37D7C6CF3E00A74B8858931C1DB2F0775378A377@SHSMSX103.ccr.corp.intel.com> <37D7C6CF3E00A74B8858931C1DB2F0775378A8AB@SHSMSX103.ccr.corp.intel.com> From: Tim Chen Message-ID: <6e8b81de-e985-9222-29c5-594c6849c351@linux.intel.com> Date: Wed, 23 Aug 2017 08:58:37 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F0775378A8AB@SHSMSX103.ccr.corp.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1191 Lines: 36 On 08/23/2017 07:49 AM, Liang, Kan wrote: >> On Tue, Aug 22, 2017 at 12:55 PM, Liang, Kan wrote: >>> >>>> So I propose testing the attached trivial patch. >>> >>> It doesn’t work. >>> The call stack is the same. >> >> So I would have expected the stack trace to be the same, and I would even >> expect the CPU usage to be fairly similar, because you'd see repeating from >> the callers (taking the fault again if the page is - once again - being migrated). >> >> But I was hoping that the wait queues would be shorter because the loop for >> the retry would be bigger. >> >> Oh well. >> >> I'm slightly out of ideas. Apparently the yield() worked ok (apart from not >> catching all cases), and maybe we could do a version that waits on the page >> bit in the non-contended case, but yields under contention? >> >> IOW, maybe this is the best we can do for now? Introducing that >> "wait_on_page_migration()" helper might allow us to tweak this a bit as >> people come up with better ideas.. > > The "wait_on_page_migration()" helper works well in the overnight testing. > Linus, Will you still consider the original patch as a fail safe mechanism? Thanks. Tim