From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6DDD3C433E6 for ; Fri, 19 Feb 2021 09:28:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D32C264EBF for ; Fri, 19 Feb 2021 09:28:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D32C264EBF Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2AFF38D0001; Fri, 19 Feb 2021 04:28:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 260756B0074; Fri, 19 Feb 2021 04:28:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 175CE8D0001; Fri, 19 Feb 2021 04:28:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0203.hostedemail.com [216.40.44.203]) by kanga.kvack.org (Postfix) with ESMTP id 0060D6B0073 for ; Fri, 19 Feb 2021 04:28:14 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id BA7A91801541F for ; Fri, 19 Feb 2021 09:28:14 +0000 (UTC) X-FDA: 77834491308.27.8E7ED7A Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf06.hostedemail.com (Postfix) with ESMTP id D7677C0001EE for ; Fri, 19 Feb 2021 09:28:14 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1613726893; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=etBn5V1fBhgd5ONghlz/8lq7lbVTQi6zy8ox4GBOZ00=; b=nvwnuVBtVcz9qfyEF2Cino+n+jhNIXXygW3mHkb2EM64MukPOVTtaNW71uYYJGpI+CM4kq NiYNVpqkkFsB1le5Ol5t/sij9v+8qYEvWrwbroIlmYHiGmN+jo56ARNNX27oqQZdsoguHD JW/AJ4bHjB70Q0QcM1QeOv0DsiofVTY= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id D377DACCF; Fri, 19 Feb 2021 09:28:12 +0000 (UTC) Date: Fri, 19 Feb 2021 10:28:12 +0100 From: Michal Hocko To: Minchan Kim Cc: David Hildenbrand , Andrew Morton , linux-mm , LKML , joaodias@google.com Subject: Re: [PATCH] mm: be more verbose for alloc_contig_range faliures Message-ID: References: <20210217163603.429062-1-minchan@kernel.org> <2f167b3c-5f0a-444a-c627-49181fc8fe0d@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D7677C0001EE X-Stat-Signature: zdqzahdabbh7w6wb9gchpnizkrjwbgh7 Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf06; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1613726894-13524 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu 18-02-21 08:19:50, Minchan Kim wrote: > On Thu, Feb 18, 2021 at 10:43:21AM +0100, David Hildenbrand wrote: > > On 18.02.21 10:35, Michal Hocko wrote: > > > On Thu 18-02-21 10:02:43, David Hildenbrand wrote: > > > > On 18.02.21 09:56, Michal Hocko wrote: > > > > > On Wed 17-02-21 08:36:03, Minchan Kim wrote: > > > > > > alloc_contig_range is usually used on cma area or movable zone. > > > > > > It's critical if the page migration fails on those areas so > > > > > > dump more debugging message like memory_hotplug unless user > > > > > > specifiy __GFP_NOWARN. > > > > > > > > > > I agree with David that this has a potential to generate a lot of output > > > > > and it is not really clear whether it is worth it. Page isolation code > > > > > already has REPORT_FAILURE mode which currently used only for the memory > > > > > hotplug because this was just too noisy from the CMA path - d381c54760dc > > > > > ("mm: only report isolation failures when offlining memory"). > > > > > > > > > > Maybe migration failures are less likely to fail but still. > > > > > > > > Side note: I really dislike that uncontrolled error reporting on memory > > > > offlining path we have enabled as default. Yeah, it might be useful for > > > > ZONE_MOVABLE in some cases, but otherwise it's just noise. > > > > > > > > Just do a "sudo stress-ng --memhotplug 1" and see the log getting flooded > > > > > > Anyway we can discuss this in a separate thread but I think this is not > > > a representative workload. > > > > Sure, but the essence is "this is noise", and we'll have more noise on > > alloc_contig_range() as we see these calls more frequently. There should be > > an explicit way to enable such *debug* messages. > > alloc_contig_range already has gfp_mask and it respects __GFP_NOWARN. > Why shouldn't people use it if they don't care the failure? > Semantically, it makes sense to me. Well, alloc_contig_range doesn't really have to implement all the gfp flags. This is a matter of practicality. alloc_contig_range is quite different from the page allocator because it is to be expected that it can fail the request. This is avery optimistic allocation request. That would suggest that complaining about allocation failures is rather noisy. Now I do understand that some users would like to see why those allocations have failed. The question is whether that information is generally useful or it is more of a debugging aid. The amount of information is also an important aspect. It would be rather unfortunate to dump thousands of pages just because they cannot be migrated. I do not have a strong opinion here. We can make all alloc_contig_range users use GFP_NOWARN by default and only skip the flag from the cma allocator but I am slowly leaning towards (ab)using dynamic debugging infrastructure for this. -- Michal Hocko SUSE Labs