Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp2031356ybh; Fri, 24 Jul 2020 02:40:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEr/Rwgq8YEGWhT6lwGNEsxya30s1SObGVx7ZFHb7TmqmWcYkWO7rWnhEzucw/lPHF3pJ/ X-Received: by 2002:a05:6402:1c10:: with SMTP id ck16mr8228180edb.72.1595583627341; Fri, 24 Jul 2020 02:40:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595583627; cv=none; d=google.com; s=arc-20160816; b=KIVLHTFH1Z7DpyTZ12GinUblRFV6M2cNqm3moPvYlZiwV4iWRSII8gmVEARklqpCJG Kca9C+7NB+5tgt0QXt0AGI7puW6L8NCK3ah5aZsMpPd3HKmXZ2thsUyovLPiawBIKMuJ w1xxivLSp65H76hh8eH0XnEaaG6juMVGe4SUpMNkx87d/18AslJUt5CRqpeyDVcJrMvY geWLt/Va/IgyDT8bmDqCqqTIhhJRAm7A+sZnazo4tn7NuSJGD2HF3dqcH+jp+GJWp7WN OqxsZTIo62ijsUL5t/H3/lU5SJHum43TUXrWPxDbV/l1FfF3vbLQvG/pNcWNUa3kcuNI Wx1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=hh7zOXaf7WsTsPfeRdRWYeTqORpAiSft9+YEEpmjxfM=; b=pdT6Z36/UBj54eZoicb+WDYJOITwsI2faNtQ8YnL4y8wQq4dXuTIrfwQM7WiRz3ezc TKwQlX9BJgIU7lYOEmuJvBB0fWpJPOt2oh270e+rtJnjGabH086SxgPo23P/8rhLJoIr BqHgB4yuR2lOfmeT9Q1I7qAoAzwcu2tf7XnVQZlm2v0cfDUTyh3g4Mv02sqw6vXK4gU1 8zS0Wr9YYPwQzZJFwRsyQJIlFyyyO0tdli3Ibj3Uyd3prXy8gdNK/SJLD5ik4R1r7b18 4/B+lX6VKIRETHEkbfw2IXvzEvd21OLiprz4isuvrSl2YM827gI8kZCSSD0pHoLz6LWG MAOg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ch2si191379edb.80.2020.07.24.02.40.04; Fri, 24 Jul 2020 02:40:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727051AbgGXJg7 (ORCPT + 99 others); Fri, 24 Jul 2020 05:36:59 -0400 Received: from mx2.suse.de ([195.135.220.15]:52698 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726114AbgGXJg7 (ORCPT ); Fri, 24 Jul 2020 05:36:59 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 28B63ACC5; Fri, 24 Jul 2020 09:37:06 +0000 (UTC) Message-ID: <0dc1e922bf87fa73790e7471b3974528dd261486.camel@suse.de> Subject: Re: [PATCH] dma-pool: Do not allocate pool memory from CMA From: Nicolas Saenz Julienne To: Amit Pundir Cc: Christoph Hellwig , Marek Szyprowski , Robin Murphy , David Rientjes , linux-rpi-kernel@lists.infradead.org, jeremy.linton@arm.com, iommu@lists.linux-foundation.org, lkml , John Stultz , Sumit Semwal Date: Fri, 24 Jul 2020 11:36:55 +0200 In-Reply-To: References: <20200708164936.9340-1-nsaenzjulienne@suse.de> <550b30a86c0785049d24c945e2c6628d491cee3a.camel@suse.de> <011994f8a717a00dcd9ed7682a1ddeb421c2c43f.camel@suse.de> <01831596e4a2a6c9c066138b23bd30435f8e5569.camel@suse.de> <6db722947546221ed99d3f473f78e1a6de65d7d6.camel@suse.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.3-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Amit, On Thu, 2020-07-23 at 10:44 +0530, Amit Pundir wrote: > Hi Nicolas, > > Sorry I got stuck on other things yesterday. No worries :) > On Tue, 21 Jul 2020 at 21:57, Nicolas Saenz Julienne [...] > > > > Let's get a bigger hammer, I'm just looking for clues here. Can you > > apply this and provide the dmesg output. > > > > diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c > > index 6bc74a2d5127..2160676bf488 100644 > > --- a/kernel/dma/pool.c > > +++ b/kernel/dma/pool.c > > @@ -268,6 +268,8 @@ void *dma_alloc_from_pool(struct device *dev, size_t size, > > schedule_work(&atomic_pool_work); > > } > > > > + dev_info(dev, "%s: size %lx, phys addr %llx, flags 0x%x\n", __func__, size, phys, flags); > > + > > return ptr; > > } > > I never made it to dma_alloc_from_pool() call from > dma_direct_alloc_pages(), dma_should_alloc_from_pool() returns False > from gfpflags_allow_blocking() block. I'm a little sceptical about this. The only way you can get memory from these pools is through dma_alloc_from_pool(), and given how changes in the pool initialization affected the phone, it's pretty clear some amount of pool allocation is happening. Regards, Nicolas