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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7F36C19F2D for ; Thu, 11 Aug 2022 08:33:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5E64D6B0073; Thu, 11 Aug 2022 04:33:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 595966B0074; Thu, 11 Aug 2022 04:33:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 45D598E0001; Thu, 11 Aug 2022 04:33:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 384C46B0073 for ; Thu, 11 Aug 2022 04:33:58 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EFF201614E0 for ; Thu, 11 Aug 2022 08:33:57 +0000 (UTC) X-FDA: 79786648914.11.B215098 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf26.hostedemail.com (Postfix) with ESMTP id 488D7140196 for ; Thu, 11 Aug 2022 08:33:57 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 257175C43C; Thu, 11 Aug 2022 08:33:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1660206836; 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=tidMnH8DkBKPELtNOqmK2muDDw/3JnV0nNhtTH1JuMw=; b=uAGQ0eH6AxTSZTu3tTxDh2JAAzGO3sfkjPwob35q44mBNm0oaevJKmJmgFTHEHaYBZ2BwH LBQaAnR+3TsCuzRwwWcUZPfbWJepb6YbzvfvJESSoUkriay5zk7R7VLjjaay7t2qzfNHnd tUFNF+feSDsmNUQPFqM91wzjpwZqwaU= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 0987A13A9B; Thu, 11 Aug 2022 08:33:55 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id EQoGO/O+9GKeVQAAMHmgww (envelope-from ); Thu, 11 Aug 2022 08:33:55 +0000 Date: Thu, 11 Aug 2022 10:33:55 +0200 From: Michal Hocko To: Christoph Hellwig Cc: Andrew Morton , Baoquan He , John Donnelly , David Hildenbrand , linux-mm@kvack.org, LKML Subject: Re: [PATCH] dma/pool: do not complain if DMA pool is not allocated Message-ID: References: <20220325122559.14251-1-mhocko@kernel.org> <20220325164856.GA16800@lst.de> <20220811072817.GB13886@lst.de> <20220811082132.GA17685@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220811082132.GA17685@lst.de> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660206837; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tidMnH8DkBKPELtNOqmK2muDDw/3JnV0nNhtTH1JuMw=; b=7dxrZC33GnDpGIcCZcujZwSVu+qcPwqRGrgzQHZKjV7Po54MO/7/xXZSPupEwQ24F3Aqp6 Z97fz8ZyXxF4+reUpHu2VQa7AuzLmDSbq9s12ODHwlet6Z8MttZFhzbjGtmYZ69as2ZEd+ WLhsOeP0sS0vPeUR5DAypEHY4Wj9Zy8= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=uAGQ0eH6; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660206837; a=rsa-sha256; cv=none; b=npnF5X/wVG0oAvV1PPkoX+cb+tGWWtqPc1Sn/6SvmtB4E6K0ppu+deXiOHPF1YVXRH7DXs OgKOslYPTawPFfUOro76iiGBh7eCdJtR39axmFHaIPNliZ95xG1lgGpR0gOSiJkLrrf+xA kRbI/WsAC0dHxOEmXcXbFgZq+Rd0Vt4= X-Stat-Signature: 5uhwggj9dmj3ynca4wt9s3adob4kk19h X-Rspamd-Queue-Id: 488D7140196 Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=uAGQ0eH6; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1660206837-919696 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 11-08-22 10:21:32, Christoph Hellwig wrote: > On Thu, Aug 11, 2022 at 10:20:43AM +0200, Michal Hocko wrote: > > Meminfo part says > > Node 0 DMA free:160kB boost:0kB min:0kB low:0kB high:0kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15996kB managed:15360kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB > > > > So the zone has 15MB of managed memory (by the page allocator), yet only > > 160kB is free early boot during the allocation. So it is mostly consumed > > by somebody. I haven't really checked by whom. > > > > Does that exaplain the above better? > > Yes. I'm really curious who eats up all the GFP_DMA memory early during > boot, though. Sorry, no idea and I do not have direct access to the machine. I can try to dig out more but, honestly, I am not sure I will find time for that. My main motivation was to reduce a shouting warning for something that doesn't indicate any real problem as this has been second (maybe third) time somebody has been complaining/asking about it. I do get your point that the sizing is probably wrong and I agree this is something that can be tuned better but I would rather vote for a useful warning when the explicit request fails rather than being to eager and warn when it is not really clear this is a problem in the first place. In both cases admin cannot really do much other than report. For the early boot we can only tell, this is not an immediate problem, just ignore. For the later we know the device and see whether we can do something about that. Just my 2c -- Michal Hocko SUSE Labs