From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by kanga.kvack.org (Postfix) with ESMTP id D36F128071E for ; Tue, 22 Aug 2017 15:30:22 -0400 (EDT) Received: by mail-oi0-f69.google.com with SMTP id g131so24886678oic.10 for ; Tue, 22 Aug 2017 12:30:22 -0700 (PDT) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com. [2607:f8b0:4003:c06::244]) by mx.google.com with ESMTPS id t130si11983963oib.238.2017.08.22.12.30.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Aug 2017 12:30:21 -0700 (PDT) Received: by mail-oi0-x244.google.com with SMTP id h4so2060260oic.2 for ; Tue, 22 Aug 2017 12:30:21 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20170822190828.GO32112@worktop.programming.kicks-ass.net> 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> <20170822190828.GO32112@worktop.programming.kicks-ass.net> From: Linus Torvalds Date: Tue, 22 Aug 2017 12:30:19 -0700 Message-ID: Subject: Re: [PATCH 1/2] sched/wait: Break up long wake list walk Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Peter Zijlstra Cc: "Liang, Kan" , Mel Gorman , Mel Gorman , "Kirill A. Shutemov" , Tim Chen , Ingo Molnar , Andi Kleen , Andrew Morton , Johannes Weiner , Jan Kara , linux-mm , Linux Kernel Mailing List On Tue, Aug 22, 2017 at 12:08 PM, Peter Zijlstra wrote: > > So that migration stuff has a filter on, we need two consecutive numa > faults from the same page_cpupid 'hash', see > should_numa_migrate_memory(). Hmm. That is only called for MPOL_F_MORON. We don't actually know what policy the problem space uses, since tthis is some specialized load. I could easily see somebody having set MPOL_PREFERRED with MPOL_F_LOCAL and then touch it from every single node. Isn't that even the default? > And since this appears to be anonymous memory (no THP) this is all a > single address space. However, we don't appear to invalidate TLBs when > we upgrade the PTE protection bits (not strictly required of course), so > we can have multiple CPUs trip over the same 'old' NUMA PTE. > > Still, generating such a migration storm would be fairly tricky I think. Well, Mel seems to have been unable to generate a load that reproduces the long page waitqueues. And I don't think we've had any other reports of this either. So "quite tricky" may well be exactly what it needs. Likely also with a user load that does something that the people involved in the automatic numa migration would have considered completely insane and never tested or even thought about. Users sometimes do completely insane things. It may have started as a workaround for some particular case where they did something wrong "on purpose", and then they entirely forgot about it, and five years later it's running their whole infrastructure and doing insane things because the "particular case" it was tested with was on some broken preproduction machine with totally broken firmware tables for memory node layout. Linus -- 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