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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4A84AC433EF for ; Tue, 3 May 2022 18:20:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241228AbiECSYL (ORCPT ); Tue, 3 May 2022 14:24:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42200 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241293AbiECSX5 (ORCPT ); Tue, 3 May 2022 14:23:57 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4DDCD62C3 for ; Tue, 3 May 2022 11:20:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B126161299 for ; Tue, 3 May 2022 18:20:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CCD95C385A9; Tue, 3 May 2022 18:20:21 +0000 (UTC) Date: Tue, 3 May 2022 19:20:18 +0100 From: Catalin Marinas To: Kefeng Wang Cc: will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, vijayb@linux.microsoft.com, f.fainelli@gmail.com Subject: Re: [PATCH v3 0/3] arm64: mm: Do not defer reserve_crashkernel() Message-ID: References: <20220411092455.1461-1-wangkefeng.wang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220411092455.1461-1-wangkefeng.wang@huawei.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 11, 2022 at 05:24:52PM +0800, Kefeng Wang wrote: > Commit 031495635b46 ("arm64: Do not defer reserve_crashkernel() for > platforms with no DMA memory zones"), this lets the kernel benifit > due to BLOCK_MAPPINGS, we could do more if ZONE_DMA and ZONE_DMA32 > enabled. > > 1) Don't defer reserve_crashkernel() if only ZONE_DMA32 > 2) Don't defer reserve_crashkernel() if ZONE_DMA with dma_force_32bit > kernel parameter(newly added) I'm not really keen on a new kernel parameter for this. But even with such parameter, there is another series that allows crashkernel reservations above ZONE_DMA32, so that would also need NO_BLOCK_MAPPINGS, at least initially. I think there was a proposal to do the high reservation first and only defer the low one in ZONE_DMA but suggested we get the reservations sorted first and look at optimisations later. If hardware is so bad with page mappings, I think we need to look at different ways to enable the block mappings, e.g. some safe break before make change of the mappings or maybe switching to another TTBR1 during boot. Does FEAT_BBM level 2 allow us to change the block size without a break before make? I think that can still trigger a TLB conflict abort, maybe we can trap it and invalidate the TLBs (the conflict should be on the linear map not where the kernel image is mapped). -- Catalin 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 22F9FC433FE for ; Tue, 3 May 2022 18:21:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NYtyugdmAJnhOibPBKe4yD/+zLGYlZLXZMOf4ZNDjaU=; b=tzVe6Qr2Cu5Qai JsL4HqBhQez+jFp9KT1zDp0dfr+rFqoydIJFAOEF7l9XZAlRObgsF7qnqEITaKmvubqJ7ELigsl3t KBw1Qqy9JtiX6joV8/D8VAFqXxYXTRzDjqq4TgeKWz4pLpCO9wwwTHAeRjXB1AAGAChgailu4bzRN ZfyLyBJ1ep4iV4KJ4Q3caGLuKHsXSGrMFHiSldPil1J3cEd2FAgxD/uI+MJc55cjzRAAiMu1fDusy yDvmmLwpPh3U+qJnjx5VGsEGnNIpIHA0gJmICh6UvCyyMhs2qSLsmpXKtiDQvvxofBuiTZT0tnk9e UMdHndz5fqcFr5LUmwSg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nlx8S-007C0P-65; Tue, 03 May 2022 18:20:32 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nlx8L-007Byo-Uw for linux-arm-kernel@lists.infradead.org; Tue, 03 May 2022 18:20:27 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 60971B81D9A; Tue, 3 May 2022 18:20:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CCD95C385A9; Tue, 3 May 2022 18:20:21 +0000 (UTC) Date: Tue, 3 May 2022 19:20:18 +0100 From: Catalin Marinas To: Kefeng Wang Cc: will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, vijayb@linux.microsoft.com, f.fainelli@gmail.com Subject: Re: [PATCH v3 0/3] arm64: mm: Do not defer reserve_crashkernel() Message-ID: References: <20220411092455.1461-1-wangkefeng.wang@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220411092455.1461-1-wangkefeng.wang@huawei.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220503_112026_183666_A5B05696 X-CRM114-Status: GOOD ( 16.80 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Apr 11, 2022 at 05:24:52PM +0800, Kefeng Wang wrote: > Commit 031495635b46 ("arm64: Do not defer reserve_crashkernel() for > platforms with no DMA memory zones"), this lets the kernel benifit > due to BLOCK_MAPPINGS, we could do more if ZONE_DMA and ZONE_DMA32 > enabled. > > 1) Don't defer reserve_crashkernel() if only ZONE_DMA32 > 2) Don't defer reserve_crashkernel() if ZONE_DMA with dma_force_32bit > kernel parameter(newly added) I'm not really keen on a new kernel parameter for this. But even with such parameter, there is another series that allows crashkernel reservations above ZONE_DMA32, so that would also need NO_BLOCK_MAPPINGS, at least initially. I think there was a proposal to do the high reservation first and only defer the low one in ZONE_DMA but suggested we get the reservations sorted first and look at optimisations later. If hardware is so bad with page mappings, I think we need to look at different ways to enable the block mappings, e.g. some safe break before make change of the mappings or maybe switching to another TTBR1 during boot. Does FEAT_BBM level 2 allow us to change the block size without a break before make? I think that can still trigger a TLB conflict abort, maybe we can trap it and invalidate the TLBs (the conflict should be on the linear map not where the kernel image is mapped). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel