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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,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 F0551C3F2D2 for ; Fri, 28 Feb 2020 19:56:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B1E9F24677 for ; Fri, 28 Feb 2020 19:56:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="AjnnrY8e" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B1E9F24677 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=broadcom.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4FAF76B0005; Fri, 28 Feb 2020 14:56:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4AC596B0006; Fri, 28 Feb 2020 14:56:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 399D36B0007; Fri, 28 Feb 2020 14:56:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0185.hostedemail.com [216.40.44.185]) by kanga.kvack.org (Postfix) with ESMTP id 227646B0005 for ; Fri, 28 Feb 2020 14:56:19 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id C5092824556B for ; Fri, 28 Feb 2020 19:56:18 +0000 (UTC) X-FDA: 76540592436.01.grade07_714b0d7ebb601 X-HE-Tag: grade07_714b0d7ebb601 X-Filterd-Recvd-Size: 6101 Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Fri, 28 Feb 2020 19:56:18 +0000 (UTC) Received: by mail-io1-f67.google.com with SMTP id h8so4805412iob.2 for ; Fri, 28 Feb 2020 11:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oS1+Ji80G02EBn4QvyRRacQTAfx4SDEzG1Ln6iEkUH4=; b=AjnnrY8efOK3e9HBoTgryIGQ3lkOxQ7JxDBT0pZiq8R1plY1+VuPaOLfBXACQ76V/p v5Me/T1hLjO7C+43MasavfQqVnIgRMAh5sHfvshgfITTOz4zybh50QD65r3XsVyQD+Et nW/dgdug1pttdZVeh1Mxr0BTn8+rtlEtu+2o0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oS1+Ji80G02EBn4QvyRRacQTAfx4SDEzG1Ln6iEkUH4=; b=lnKQ5QA1M2mc5KbrY9Y9aOiCqWhiuHEGvPUumTFo4AFlp4LyGL7uoZhqGKwwTWCh2J G15tYrHSnDjErk9Y9UPaaqreRcMoJgybQO2iK4QAnYUFX7xPxQvxJ3hivpp+/Ey9rvVP WZiPm+3At5fE/0l523TrJKGEFSAgHy11iQPZ0OEA2DrdEd8BRbJ62dg6EWCKcjw+E+02 ZOoc+4TjAS2pebz1YZFs4QSfchQP2JxBgaSlvKxqNGTpGdk05nX2cKnlBNWPP6XhYVXb EzY1iY5fsmmKnAM+cmXbMPgrDvtgRGpM3XY07msjda6oq1NRvO70yxycIl6xpaBLnYgE 32Dw== X-Gm-Message-State: APjAAAUslKoGdC9OjF9Vt8SN/dhOXeSRh8WN+CQyWsoFSEfj6/dxNfxP PSAWfoUVwMLMLoDNM6KdxN7eDubRiPpfJMmBHYBqGg== X-Google-Smtp-Source: APXvYqzbP2H8I9c8cRV0ntwz96JSXUgDWTco16U/tNfHAu9vP3li44WVQfhUvxjdiAe8SevIn10XGsW8nuky5AfecQM= X-Received: by 2002:a5d:824c:: with SMTP id n12mr114637ioo.234.1582919777609; Fri, 28 Feb 2020 11:56:17 -0800 (PST) MIME-Version: 1.0 References: <8f82edf2-7313-eb4c-f68e-ff18f7a5e919@suse.cz> <20200227174838.GI3281767@arrakis.emea.arm.com> In-Reply-To: <20200227174838.GI3281767@arrakis.emea.arm.com> From: Jonathan Richardson Date: Fri, 28 Feb 2020 11:56:06 -0800 Message-ID: Subject: Re: cma can't activate area on arm64 To: Catalin Marinas Cc: Vlastimil Babka , linux-mm@kvack.org, akpm@linux-foundation.org, "linux-arm-kernel@lists.infradead.org" , Nicolas Saenz Julienne , Robin Murphy Content-Type: text/plain; charset="UTF-8" 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, Feb 27, 2020 at 9:48 AM Catalin Marinas wrote: > > On Thu, Feb 27, 2020 at 10:56:12AM +0100, Vlastimil Babka wrote: > > On 2/22/20 12:42 AM, Jonathan Richardson wrote: > > > As of the 5.5 kernel I see boot errors in cma. It reserves 1G and then can't > > > activate an area. I added some prints. It's trying to activate the DMA > > > zone. This causes a driver to fail allocating a dma pool later on. The > > > coherent pool is the default 256MB. If I reduce cma from 1G to 512M > > > then it only tries activates DMA32 zone. I assume there was not enough cma > > > memory for DMA zone? Are there any configuration changes required due > > > to the DMA_ZONE and DMA_ZONE32 changes? I've attached my boot log. > > > > I think this question is better for the ARM guys. CC'd > > With commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32"), we > limited ZONE_DMA to 1G to accommodate the RPi4 requirements. ZONE_DMA32 > spans to the end of the 32-bit space. So with a CMA region that goes > across the 1st GB, you'd hit this problem. > > The dma_contiguous_reserve() call in arm64 uses ZONE_DMA32 as the upper > limit under the assumption that you don't need CMA in ZONE_DMA. But this > one doesn't have a lower limit. > > What platform is this and how to you request the CMA size (cmdline)? This is stingray (arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts). cma is specified on cmdline as "cma=1G". The full boot log was in the attachment. Do > you use a fixed base? Also, do you want the CMA in ZONE_DMA or > ZONE_DMA32? I'm not sure which zone we want it in. I'm assuming ZONE_DMA32. Before that change there was only one zone. If I disable ZONE_DMA I don't see the error, though I haven't tested anything. I don't really understand why ZONE_DMA is enabled by default if it's a requirement for Rpi only. I'm assuming it should work as is with both zones enabled but not clear how cma spans the two zones. Was there a reason for having both zones enabled as the default? > > > > [ 0.000000] cma: Reserved 1024 MiB at 0x00000000a0000000 > > > ... > > > [ 0.390448] Activating cma name: reserved, zone name: DMA > > > [ 0.396564] pfn = 0xa0000 > > > [ 0.399522] cma->count = 262144 > > > [ 0.406244] pfn failed on = c0000 > > > [ 0.410002] cma: CMA area reserved could not be activated > > > > > > static int __init cma_activate_area(struct cma *cma) > > > { > > > ... > > > printk("Activating cma name: %s, zone name: %s\n", cma->name, zone->name); > > > printk("pfn = 0x%lx\n", pfn); > > > printk("cma->count = %lu\n", cma->count); > > > > > > do { > > > unsigned j; > > > > > > base_pfn = pfn; > > > for (j = pageblock_nr_pages; j; --j, pfn++) { > > > WARN_ON_ONCE(!pfn_valid(pfn)); > > > /* > > > * alloc_contig_range requires the pfn range > > > * specified to be in the same zone. Make this > > > * simple by forcing the entire CMA resv range > > > * to be in the same zone. > > > */ > > > if (page_zone(pfn_to_page(pfn)) != zone) { > > > printk("pfn failed on = 0x%lx\n", pfn); > > > goto not_in_zone; > > So I guess it's this test that fails as the CMA now spans ZONE_DMA and > ZONE_DMA32. Yes it fails here.