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 54E6FC433F5 for ; Mon, 23 May 2022 08:17:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231694AbiEWIRW (ORCPT ); Mon, 23 May 2022 04:17:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231670AbiEWIRR (ORCPT ); Mon, 23 May 2022 04:17:17 -0400 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D843E25587 for ; Mon, 23 May 2022 01:17:15 -0700 (PDT) Received: from mail-yb1-f171.google.com ([209.85.219.171]) by mrelayeu.kundenserver.de (mreue012 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MODeL-1oCX0i35Dt-00OWyn for ; Mon, 23 May 2022 10:17:13 +0200 Received: by mail-yb1-f171.google.com with SMTP id z7so2778842ybf.7 for ; Mon, 23 May 2022 01:17:13 -0700 (PDT) X-Gm-Message-State: AOAM530fQqFaZa7WPvH41eeVsuSESxDt2jlk2Wx+sU/vN4ZYujv0Dvbk R1/7FJhm7ZdpCRM+CAT3qTohNa2HPT0p5wreXyY= X-Google-Smtp-Source: ABdhPJwpBo10pOgBdqfC/NkZnjBYRstzV66KiRkOk2ZhvrzK49G4qlPbyegUfcvAyICBzxOuMbxaHVqbOn8oBK9jnSk= X-Received: by 2002:a25:c747:0:b0:64f:62fb:f55e with SMTP id w68-20020a25c747000000b0064f62fbf55emr13378958ybe.106.1653293832593; Mon, 23 May 2022 01:17:12 -0700 (PDT) MIME-Version: 1.0 References: <20220307140804.1400-1-jszhang@kernel.org> In-Reply-To: From: Arnd Bergmann Date: Mon, 23 May 2022 10:16:56 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] riscv: add irq stack support To: Jisheng Zhang Cc: Arnd Bergmann , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:3mvfU8MEw7zAZ2vwDUR0VEJ7gLIarGDDwRYYoWCDsTx7aSH7UVF L+lhVqI4BtLrdZjGMDTSA6zkgTgwf08nwlkVjHEGH6BI05upf5gL3ZngWnIE6k0vdYAEtYN XoRm/OkEPaDBYpbo7p53Y4njWw8OGG9GeJaGaHHp48YizAGTBDYuIrDMUrWQWtaOLO320Gf 42daTkxAbeMFEvuiid4xQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:bnuN2gPifV0=:nOOywJmXYXyGbFHsu4taLO lT/TkiL7crpLFLzZV8WqF4MfuJS0onNfklH5hSTQKQat8SER3SJMEkUTEEtHTONSv2WfBzQng lCI3Azv2hiDmtIFtS574CK8XvB7ycZuSvaebVV4rfIo+79MHHe5P52c61gjO87L3NC5ozAUji 76PXab7pZ7BINgjt9lOHcEjdD7ZKUHXKXCllo9sVeu3wx/zeF71NFfuKBGlmkw9vSuJDfCe/A drGHBBP02EdRuhSTZrfms7YuUbeTWZgw/+6fnPDfq67WGKGLqIXuXZghwY7eYWj3ON6L/n8QT wN+Y4lm71O+OJqe7yI6ztz59aO0hY6AQw44m26x7+GD8+A8B8XsHt6C1f4LreMClQ12VojSJE HSA+VPOGv8Iv+0WX1NwybCE1HjLBMZMgBEUMQI442L+mk2hwS7JCbeOQmqgiYpQs6EL7sI0qG Pv1ZOKygNhoe3OBT4kKVr+hZZ49rMviE/wFTYntFwBVKDeQl4wCwJwM1d8NWUjEYVRlhO8reG UTURwZJUW7Di2Amnc8qSC7N28G49CGexgiktn2tkQW4lLq8/up+vfLnDqHLpGmWAhbZrOHVqB yoWcC7ybGIZ1gbh4u11hrpOp8kcm/SKsimzUfYgJ+N3Za9GQqq4PZZnIkamB1IAVZUEXvBdcB p0Fxs1mpgmO1rqL5HN3VJgD2afe76iwVyggh1xgktarjfrPUPvXu/wa646WKYJu0lubJnd4CM jHc/pz8SO6Nt0g9wyIhrj7D1i9H8kT5tDIqu81/mfabNYB4Yi+6BjKM4cSZH402kEG9i+01bh e8ano53UC/bL1Ql7rTGjqZvgvnnQr0GXnIWDhMePNVQ/y/yIoyu2EcNAK5t8MYqmAjmCJbLYt 44HyoLHbW2M7DSL0OZ2sj4DtcUvIZrJAfYREenA/0= Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 15, 2022 at 7:14 AM Jisheng Zhang wrote: > On Mon, Mar 07, 2022 at 08:19:35PM +0100, Arnd Bergmann wrote: > > On Mon, Mar 7, 2022 at 3:08 PM Jisheng Zhang wrote: > > > +2: > > > > What is the benefit of doing this in assembler? Is it measurably faster? > > > > I see that arm64 does the same thing in C code, and it would be best to > > have a common implementation for doing this, in terms of maintainability. > > > > Sorry for delay. The assembler code is mainly to cal the stack ptr then > change the SP to use the stack, which equals to arm64 call_on_irq_stack() > which is implemented in assembler too. I understand that you need to be in asm code to switch the stack, it just felt that the arm64 method is a bit easier to debug here. I suppose being able to keep using generic_handle_arch_irq() is also beneficial, so it doesn't make much difference either way. > > > + for_each_possible_cpu(cpu) { > > > +#ifdef CONFIG_VMAP_STACK > > > + void *s = __vmalloc_node(IRQ_STACK_SIZE, THREAD_ALIGN, > > > + THREADINFO_GFP, cpu_to_node(cpu), > > > + __builtin_return_address(0)); > > > +#else > > > + void *s = (void *)__get_free_pages(GFP_KERNEL, get_order(IRQ_STACK_SIZE)); > > > +#endif > > > > On a related topic: is there a reason to still keep the non-VMAP_STACK > > irq stack is 16KB on RV64 now, vmalloc doesn't gurantee physical > continuous pages, I want to keep the stack physical continuous > characteristic for !VMAP_STACK case. I don't understand. What is the benefit of having a physically continuous stack? If this is required for something, you could still get that with a VMAP stack by using alloc_pages() to allocate the stack and them using vmap() to put it into the vmalloc range with appropriate guard pages. I think we really want to avoid the case of missing guard pages around the stack, and eliminate the part where the stack is in the linear map. Arnd 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 85F4FC433FE for ; Mon, 23 May 2022 09:09:59 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NfOYKxNj4Tr+dz5Fu3F7vwf2XhStrUHxTm33LS5sp8g=; b=vcA7QOoLbqUW9Q crfL0j8gq2VEqOTeTHI8kGw89mmLI/aw62Tb0MBw9eUZubEf8Gfw/RcoO5O7HudP+oMi4bESK6JjZ mU705SFoGYFZV6MaWN4SRbhyg4fE/L8dpckX8lDdZ9fvTW0yD6JwdfhcSJ92cyFxhxZptcKtxK2ot +LHZ/rYQq6yLZTK7EUIKELmClvD2BB93/K1BXa7zPGW9gg3JBiPlUoB3Fz6iBCMDgOx8JCK0lXK70 OIIj0kVAjxSaGPPknOM5SldPQnXcyf/zlWXxKckRrNRhIbGlujTHt89db2PEqrzV5S0ivS70ld8fJ fCOIudHfvzkWu9V2Pdhg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nt44U-002iwO-5E; Mon, 23 May 2022 09:09:50 +0000 Received: from mout.kundenserver.de ([212.227.17.13]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nt3Fk-002Mhy-Kx for linux-riscv@lists.infradead.org; Mon, 23 May 2022 08:17:26 +0000 Received: from mail-yb1-f173.google.com ([209.85.219.173]) by mrelayeu.kundenserver.de (mreue106 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MnqbU-1nUV0t3Glm-00pHdU for ; Mon, 23 May 2022 10:17:13 +0200 Received: by mail-yb1-f173.google.com with SMTP id q135so24047389ybg.10 for ; Mon, 23 May 2022 01:17:13 -0700 (PDT) X-Gm-Message-State: AOAM531D4RN3cKiT5zrXiK/iObbU4BGcu96eCaNGDUX0QFYZYt1RN7HK yFx6SEG3jptLgnZuKu9uCO5g/MYo9vORu4joIzY= X-Google-Smtp-Source: ABdhPJwpBo10pOgBdqfC/NkZnjBYRstzV66KiRkOk2ZhvrzK49G4qlPbyegUfcvAyICBzxOuMbxaHVqbOn8oBK9jnSk= X-Received: by 2002:a25:c747:0:b0:64f:62fb:f55e with SMTP id w68-20020a25c747000000b0064f62fbf55emr13378958ybe.106.1653293832593; Mon, 23 May 2022 01:17:12 -0700 (PDT) MIME-Version: 1.0 References: <20220307140804.1400-1-jszhang@kernel.org> In-Reply-To: From: Arnd Bergmann Date: Mon, 23 May 2022 10:16:56 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] riscv: add irq stack support To: Jisheng Zhang Cc: Arnd Bergmann , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv , Linux Kernel Mailing List X-Provags-ID: V03:K1:ETMQ0ELg/6PB7bFqxs2o6hAG8eurGuLaVAOWbSuBWYg7q3zQt8L mjHTsV751oCbgyQi8fl8d+UfT3/doJXhHjzd/OHPBX1sLzJqhXOYbowvzDl30ZIuG67gh25 e0OeYxIT6rrgsEipFVctYIiK6TdJ9/Rw/pjipIMxzxY93Dg0b8HiOUcJWypqFwEfYuvuerW yAo3sc/TBquknxNzeFTQg== X-UI-Out-Filterresults: notjunk:1;V03:K0:DvVcwkcHscM=:1+9+be9mBTZQsa5T2MEUJ2 JxjvCDazDN9p3i15NNc7WSKhgllFkBmww2WhnlaXojQwewobVtym2fa3uhSWv6Wn2glhzEp6d WXNrLY6Zhij9Kdc/i9ygi7kI6s57GYX3KREJZElHfMlWx78A+BgSZ/njQciXF4LD7yF/P4BaS k+rL4z/LFtyNyRwKkDypvpNRiobDWVJ9OspZcDdYesnt4KsUikEes0i26x8TAXo0B96m916yg 2szWGBks2hU6oNhClqotcZOPkoXgZX9/3rLNoK1tZlBZqdv+uDCMv9FEBARP1yKWN8rCxlTTk IAXXkudbtVB877SC7cRoNvS2TAB7WcODMfInbNYuk0xUN/9j1nJvuvm6c4RzenWsf9FCI19FV wtJv/UmbAYc+q4L5wd2Mkx67EcuDK4NHjNymBRqG207wCHz6n+yxgzSF4ASfUwK4ga4fnUg/L huxM3Td+tGfH1S+k9wVrtok28Kqt/+S6UpGOHfgxK7fYbSXLvv9qVlODKSrbdsJ6W4GwPb7fr sFqpJe2prBRDTKXEFfftE1MYawiluvU46G5mpkg8KWdBuUQgu6xBb/y5EiaqWax/900umm2g4 RhZks478kpa1iDoizEkrXj+/OLB+FhjH1yZkSNhL+TIEKpvD0ZEDIwHc/YI7Ts3qQkwf/kf+L /kGGh8ZKFX2osoXX4q1TJg5JMkLSEM1cLx0blM8AKSFQvs3oZMkAatvU1LBuaGXZekhKJGvND 4x9g/Mw1FnTY5HXXO0We94yPEkYxjwtKLNF50d8M8By+A6L5WCcMGqNLwTwwe68EHo7nOZX5G wJN57AwUzjLPwN/Bhz0IzwDnqYsK3eCgh6yuxMUUy/j0StfqsM2R2adlGGTzkw6P33vitnzna 3Ncuiw2SRBIeLZOW5wBF0n8WrlQRmn921Vrxk+jdQ= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220523_011725_026197_E525D75C X-CRM114-Status: GOOD ( 23.90 ) X-BeenThere: linux-riscv@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-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Sun, May 15, 2022 at 7:14 AM Jisheng Zhang wrote: > On Mon, Mar 07, 2022 at 08:19:35PM +0100, Arnd Bergmann wrote: > > On Mon, Mar 7, 2022 at 3:08 PM Jisheng Zhang wrote: > > > +2: > > > > What is the benefit of doing this in assembler? Is it measurably faster? > > > > I see that arm64 does the same thing in C code, and it would be best to > > have a common implementation for doing this, in terms of maintainability. > > > > Sorry for delay. The assembler code is mainly to cal the stack ptr then > change the SP to use the stack, which equals to arm64 call_on_irq_stack() > which is implemented in assembler too. I understand that you need to be in asm code to switch the stack, it just felt that the arm64 method is a bit easier to debug here. I suppose being able to keep using generic_handle_arch_irq() is also beneficial, so it doesn't make much difference either way. > > > + for_each_possible_cpu(cpu) { > > > +#ifdef CONFIG_VMAP_STACK > > > + void *s = __vmalloc_node(IRQ_STACK_SIZE, THREAD_ALIGN, > > > + THREADINFO_GFP, cpu_to_node(cpu), > > > + __builtin_return_address(0)); > > > +#else > > > + void *s = (void *)__get_free_pages(GFP_KERNEL, get_order(IRQ_STACK_SIZE)); > > > +#endif > > > > On a related topic: is there a reason to still keep the non-VMAP_STACK > > irq stack is 16KB on RV64 now, vmalloc doesn't gurantee physical > continuous pages, I want to keep the stack physical continuous > characteristic for !VMAP_STACK case. I don't understand. What is the benefit of having a physically continuous stack? If this is required for something, you could still get that with a VMAP stack by using alloc_pages() to allocate the stack and them using vmap() to put it into the vmalloc range with appropriate guard pages. I think we really want to avoid the case of missing guard pages around the stack, and eliminate the part where the stack is in the linear map. Arnd _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv