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 6B8B3C433F5 for ; Fri, 17 Dec 2021 11:39:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 148176B0073; Fri, 17 Dec 2021 06:39:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F88A6B0075; Fri, 17 Dec 2021 06:39:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F02C76B0078; Fri, 17 Dec 2021 06:39:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0241.hostedemail.com [216.40.44.241]) by kanga.kvack.org (Postfix) with ESMTP id E3CE96B0073 for ; Fri, 17 Dec 2021 06:39:08 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A83D3181AC9C6 for ; Fri, 17 Dec 2021 11:38:58 +0000 (UTC) X-FDA: 78927089556.13.718AC5E Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) by imf04.hostedemail.com (Postfix) with ESMTP id 372854001D for ; Fri, 17 Dec 2021 11:38:58 +0000 (UTC) Received: by mail-pg1-f170.google.com with SMTP id 200so1840917pgg.3 for ; Fri, 17 Dec 2021 03:38:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Mul3ZRNFflTWXV4x8BSchYuRZDr6/Zs4AviyHDR6Mbs=; b=N72GbVk1j2sTQmOoAz6wPf7Xl+fFMpDg6FcOzAKqdWrwCxCiisp1Z5RZC4ue0Vf1v4 jerBHr3qfyIwjpTcwoy2aINXfiIv9toma5YuCaGZxVCB1PVoEv4WSJCfgwikGMe/68aN oXhdgbcMKGf84GwKJWD7ydQcF2o2cOa8F67bJqeV8Tbk+yiMcpWvlPHhU6ASD5wHp21R ArmgN1ndqfxsgG1ZDGzoYK5xurGxX2iWr00lzNVcwH4K2Ssg8cWfpe9XMua2hvi4RFQN Gsj4NwCsSUE9t4skP6aA91q3W813wKHxsfeXl6tZg84eH9Ld4GmAMxKw9FAGAoQ4meDt TEIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Mul3ZRNFflTWXV4x8BSchYuRZDr6/Zs4AviyHDR6Mbs=; b=jfkE4rL4dKcDBxTSjcbrZo0cC3Lj1lrwuUuzqSvpilVummR9nhYZ+vRPlKfM/LwhED kHGJADREQpyns1+7ICcO0b3OuarvX6F3WuaFyz0ZrMOPExFUjWoTD00vFSaHq++Bq3gf oV1/LtrOK7iP5JwN1Q+4ZMmdUg5kbg5O1sxvBfVUanXt9xg1aqtXiELEXR71GSNb90qw 6a+475YuC8xuY6If8SwlMpgkMBSNsMClMW3vSPeYML1o2cY2KuEpJjwkv3oyugCFU6uB Z2sTwcSoRLCCdrxz0s3SwQAjnI41PWUM9NeDggJLu/4dnHuorCPPrE6pHiIA+ip1lnRR shTg== X-Gm-Message-State: AOAM532QVlQYyWFKMXMHKPHwC/GnnHLjxMqEBcIKPnmVZxmFv+yZnrZh HTMr1v0Sx/4yMmXWQAJxs80= X-Google-Smtp-Source: ABdhPJz0Lqy/grEZdHR3OmyTYAVpGmR4r88Bqsau2CdVvZCbJ7jRDqcOJ7/LTvXWZkORmPlBVf5Fww== X-Received: by 2002:a63:d907:: with SMTP id r7mr2533764pgg.406.1639741137165; Fri, 17 Dec 2021 03:38:57 -0800 (PST) Received: from ip-172-31-30-232.ap-northeast-1.compute.internal (ec2-18-181-137-102.ap-northeast-1.compute.amazonaws.com. [18.181.137.102]) by smtp.gmail.com with ESMTPSA id e15sm1702548pga.53.2021.12.17.03.38.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Dec 2021 03:38:56 -0800 (PST) Date: Fri, 17 Dec 2021 11:38:52 +0000 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Christoph Hellwig Cc: Vlastimil Babka , Baoquan He , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, cl@linux.com, John.p.donnelly@oracle.com, kexec@lists.infradead.org, stable@vger.kernel.org, Pekka Enberg , David Rientjes , Joonsoo Kim Subject: Re: [PATCH v3 5/5] mm/slub: do not create dma-kmalloc if no managed pages in DMA zone Message-ID: References: <20211213122712.23805-1-bhe@redhat.com> <20211213122712.23805-6-bhe@redhat.com> <20211213134319.GA997240@odroid> <20211214053253.GB2216@MiWiFi-R3L-srv> <20211215044818.GB1097530@odroid> <20211215070335.GA1165926@odroid> <20211215072710.GA3010@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211215072710.GA3010@lst.de> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 372854001D X-Stat-Signature: hqp53o7mok5ejhb4ptkpbm5wyg1xczks Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=N72GbVk1; spf=pass (imf04.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.215.170 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1639741138-2241 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 Wed, Dec 15, 2021 at 08:27:10AM +0100, Christoph Hellwig wrote: > On Wed, Dec 15, 2021 at 07:03:35AM +0000, Hyeonggon Yoo wrote: > > I'm not sure that allocating from ZONE_DMA32 instead of ZONE_DMA > > for kdump kernel is nice way to solve this problem. > > What is the problem with zones in kdump kernels? > > > Devices that requires ZONE_DMA memory is rare but we still support them. > > Indeed. > > > > 1) Do not call warn_alloc in page allocator if will always fail > > > to allocate ZONE_DMA pages. > > > > > > > > > 2) let's check all callers of kmalloc with GFP_DMA > > > if they really need GFP_DMA flag and replace those by DMA API or > > > just remove GFP_DMA from kmalloc() > > > > > > 3) Drop support for allocating DMA memory from slab allocator > > > (as Christoph Hellwig said) and convert them to use DMA32 > > > > (as Christoph Hellwig said) and convert them to use *DMA API* > > > > > and see what happens > > This is the right thing to do, but it will take a while. In fact > I dont think we really need the warning in step 1, Hmm I think step 1) will be needed if someone is allocating pages from DMA zone not using kmalloc or DMA API. (for example directly allocating from buddy allocator) is there such cases? > a simple grep > already allows to go over them. I just looked at the uses of GFP_DMA > in drivers/scsi for example, and all but one look bogus. > That's good. this cleanup will also remove unnecessary limitations. > > > > > Yeah, I have the same guess too for get_capabilities(), not sure about other > > > > > callers. Or, as ChristophL and ChristophH said(Sorry, not sure if this is > > > > > the right way to call people when the first name is the same. Correct me if > > > > > it's wrong), any buffer requested from kmalloc can be used by device driver. > > > > > Means device enforces getting memory inside addressing limit for those > > > > > DMA transferring buffer which is usually large, Megabytes level with > > > > > vmalloc() or alloc_pages(), but doesn't care about this kind of small > > > > > piece buffer memory allocated with kmalloc()? Just a guess, please tell > > > > > a counter example if anyone happens to know, it could be > > > > > easy. > > The way this works is that the dma_map* calls will bounce buffer memory > that does to fall into the addressing limitations. This is a performance > overhead, but allows drivers to address all memory in a system. If the > driver controls memory allocation it should use one of the dma_alloc_* > APIs that allocate addressable memory from the start. The allocator > will dip into ZONE_DMA and ZONE_DMA32 when needed.