Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2432436imm; Mon, 10 Sep 2018 00:41:07 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbkjrfoLqxi6KIM5GuMYvwA1ilt6IJNzCsMUnprNGW9loQbeev/NQKC2/piS2hRQrvLOTwQ X-Received: by 2002:a17:902:8bc4:: with SMTP id r4-v6mr19861480plo.124.1536565267065; Mon, 10 Sep 2018 00:41:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536565267; cv=none; d=google.com; s=arc-20160816; b=wW/THII+0uijNG6A2HKVOCjGCkXW7YmOGz8FUnx7AmIFLbq8r+kpnS8XJCJ5iVnMXd BCuQRq7TTs53Al2DKcFmAq5dRZTVFEs3BL6uwNaBKDnMKgCp/wN5RNVOtGopIByHGHiI AZbYpYS0lJd2FepHx3Tpd3jfqUIxOKC1pxckD4WeJHbO2dwrrHkup4AaZsObiS+rIDZZ BbXIbAYWPPd0s2qrFhaER6P+k1+4Vf5xe+mfJB3qjy5uVJB9X6IrAZ5Iq6W3/NXmXCjI g5BgWdPMWvUjGhoKNmpFvvvGsWKgN1MykvSkdG0AumDsy8ypbFKnGo5eI4DUSISyOfQZ bEqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ZLCuSm8XJy0sIzqIOeeWkiucG05am3ClhdtIl11BEQQ=; b=YBKuC0218oUuLxNQYIVFl6FgdFRGq79LZ/nCUzHMUoMuLWEyBNfsCwDI1uXzYKeqSR YkXEoP1GTpqBoTlHH/WoN2lQpvEB7pv8YU+RB3uV9GYrMeq/+8VZA8Wr1kYnqoeH1RND hRQHuifdWxxSrAORxY935cMTpWIVw6ztYuTS50kb5QZrhrbF0r9WrfTVwnlCBqYxgvKK HAvIaSbvuk6EesBV6dUL6ANIRnHJDLTpskvwOBv08pCVQ15EyvpYs+QI5jleoNeO+KGi p255+oQclbWJguw4EHgeGX7X7kd4DGOrNS6y1AOHV0MH+4k/mQtlPtl5mImfLEH8uYaR D5/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s29-v6si16043769pgn.47.2018.09.10.00.40.51; Mon, 10 Sep 2018 00:41:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727877AbeIJMcX (ORCPT + 99 others); Mon, 10 Sep 2018 08:32:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:51058 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727069AbeIJMcW (ORCPT ); Mon, 10 Sep 2018 08:32:22 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 90C46AEF6; Mon, 10 Sep 2018 07:39:40 +0000 (UTC) Date: Mon, 10 Sep 2018 09:39:38 +0200 From: Michal Hocko To: Stefan Priebe - Profihost AG Cc: Andrew Morton , Andrea Arcangeli , David Rientjes , Zi Yan , "Kirill A. Shutemov" , linux-mm@kvack.org, LKML Subject: Re: [PATCH] mm, thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings Message-ID: <20180910073938.GA16723@dhcp22.suse.cz> References: <20180907130550.11885-1-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Cc Vlastimil. The full report is http://lkml.kernel.org/r/f7ed71c1-d599-5257-fd8f-041eb24d9f29@profihost.ag] On Sat 08-09-18 20:52:35, Stefan Priebe - Profihost AG wrote: > [305146.987742] khugepaged: page allocation stalls for 224236ms, order:9, > mode:0x4740ca(__GFP_HIGHMEM|__GFP_IO|__GFP_FS|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_THISNODE|__GFP_MOVABLE|__GFP_DIRECT_RECLAIM), nodemask=(null) This is certainly not a result of this patch AFAICS. khugepaged does add __GFP_THISNODE regardless of what alloc_hugepage_khugepaged_gfpmask thinks about that flag. Something to look into as well I guess. Anyway, I guess we want to look closer at what compaction is doing here because such a long stall is really not acceptable at all. Maybe this is something 4.12 kernel related. This is hard to tell. Unfortunatelly, upstream has lost the stall warning so you wouldn't know this is the case with newer kernels. Anyway, running with compaction tracepoints might tell us more. Vlastimil will surely help to tell you which of them to enable. -- Michal Hocko SUSE Labs