From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753188AbcHPAPw (ORCPT ); Mon, 15 Aug 2016 20:15:52 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:33573 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752958AbcHPAPu (ORCPT ); Mon, 15 Aug 2016 20:15:50 -0400 MIME-Version: 1.0 In-Reply-To: References: <20160815004826.GW19025@dastard> <20160815022808.GX19025@dastard> <20160815050016.GY19025@dastard> <20160815222211.GA19025@dastard> <20160815224259.GB19025@dastard> From: Linus Torvalds Date: Mon, 15 Aug 2016 17:15:47 -0700 X-Google-Sender-Auth: PEgmA2BJ6ehev3yCciOpgLcG4Pc Message-ID: Subject: Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression To: Dave Chinner , Mel Gorman , Johannes Weiner , Vlastimil Babka Cc: Bob Peterson , "Kirill A. Shutemov" , "Huang, Ying" , Christoph Hellwig , Wu Fengguang , LKP , Tejun Heo , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 15, 2016 at 4:20 PM, Linus Torvalds wrote: > > But I'll try to see what happens > on my profile, even if I can't recreate the contention itself, just > trying to see what happens inside of that region. Yeah, since I run my machines on encrypted disks, my profile shows 60% kthread, but that's just because 55% is crypto. I only have 5% in kswapd. And the spinlock doesn't even show up for me (but "__delete_from_page_cache()" does, which doesn't look unreasonable). And while the biggest reason the spinlock doesn't show up is likely simply my single-node "everything is on one die", I still think the lower kswapd CPU use might be partly due to the node-vs-zone thing. For me, with just one node, the new test_bit(PGDAT_WRITEBACK, &pgdat->flags)) { ends up being very similar to what we used to have before, ie test_bit(ZONE_WRITEBACK, &zone->flags)) { but on a multi-node machine it would be rather different. So I might never see contention anyway. The basic logic in shrink_swap_list() goes back to commit 283aba9f9e0 ("mm: vmscan: block kswapd if it is encountering pages under writeback") but it has been messed around with a lot (and something else existed there before - we've always had some "throttle kswapd so that it doesn't use insane amounts of CPU time"). DaveC - does the spinlock contention go away if you just go back to 4.7? If so, I think it's the new zone thing. But it would be good to verify - maybe it's something entirely different and it goes back much further. Mel - I may be barking up entirely the wrong tree, but it would be good if you could take a look just in case this is actually it. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============3273956374945751790==" MIME-Version: 1.0 From: Linus Torvalds To: lkp@lists.01.org Subject: Re: [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression Date: Mon, 15 Aug 2016 17:15:47 -0700 Message-ID: In-Reply-To: List-Id: --===============3273956374945751790== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, Aug 15, 2016 at 4:20 PM, Linus Torvalds wrote: > > But I'll try to see what happens > on my profile, even if I can't recreate the contention itself, just > trying to see what happens inside of that region. Yeah, since I run my machines on encrypted disks, my profile shows 60% kthread, but that's just because 55% is crypto. I only have 5% in kswapd. And the spinlock doesn't even show up for me (but "__delete_from_page_cache()" does, which doesn't look unreasonable). And while the biggest reason the spinlock doesn't show up is likely simply my single-node "everything is on one die", I still think the lower kswapd CPU use might be partly due to the node-vs-zone thing. For me, with just one node, the new test_bit(PGDAT_WRITEBACK, &pgdat->flags)) { ends up being very similar to what we used to have before, ie test_bit(ZONE_WRITEBACK, &zone->flags)) { but on a multi-node machine it would be rather different. So I might never see contention anyway. The basic logic in shrink_swap_list() goes back to commit 283aba9f9e0 ("mm: vmscan: block kswapd if it is encountering pages under writeback") but it has been messed around with a lot (and something else existed there before - we've always had some "throttle kswapd so that it doesn't use insane amounts of CPU time"). DaveC - does the spinlock contention go away if you just go back to 4.7? If so, I think it's the new zone thing. But it would be good to verify - maybe it's something entirely different and it goes back much further. Mel - I may be barking up entirely the wrong tree, but it would be good if you could take a look just in case this is actually it. Linus --===============3273956374945751790==--