Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp5255871pxu; Wed, 21 Oct 2020 18:59:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz/HE1Whj47WHMemjoYCGT7gBn3KrMQbc3sax5LDY1gTu4jwCrrkznuC5cbOLk8KozYgGyq X-Received: by 2002:a17:907:2090:: with SMTP id pv16mr208404ejb.506.1603331941678; Wed, 21 Oct 2020 18:59:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603331941; cv=none; d=google.com; s=arc-20160816; b=aPXSIOMSr6y23wR+VkG1ntzIISIqoZV3kgp7gRkw/0Dl+ArZDRxTRq9CNf5SksoiO1 3t1yjYpXiwOgwg+tRSrl9ja8TxLYMc/S55jaHotU5tc0FqZ31V3dX8BouUclFdD0JPSc 7ACxY0VraGhSFfjOA43RjXd6qN5sCkWPbzyiw+M8TEZrbzDQRABA/JY8rptlMmw/5JaV M7GCgH+hVCAyX2K5sL/KMQY6dLmwIOb/yKG3A9pS5gEOAhUI+8TsUQe0VZpSed0nt6qv HdTqG9hho666FMVwgx736mbcD5bdNtBLzZvA/G1T57PL99KYaaBWG6yEt7Z572tgzppM ujLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:cms-type:content-transfer-encoding :date:message-id:in-reply-to:cc:to:from:sender:reply-to:subject :mime-version:dkim-signature:dkim-filter; bh=wjrduFjgfm07XfY7v3+tVmfXvRbDBj4UbIFGVRu6kkY=; b=LwrHH17lCD3W4ARWVCnwrXI4hY2nomxKv/33wp3+Yw/YYgYZWmebYiuke1MVy0F+Sd xEDtV+SVucO1CbVI9MPPEUITm4TNrPmq4wAJETr8zmQF0tPc1/+LIquhMvww56KW8aFa REKim8sn2V4LwGxYrMX6nPNB/tnHaNdQ9ukGI5TumN88Nmq9BI1MHa6oo86eF0ONv5kn UfoUCEOM/JQz/yBirmN9CDPD5hD2Vx/Kx6P4b8wXskWYjHh4/+VYFGSDSkm/zX6eK3aD fEMsnieVCPMfDBaanJGnmGg+wHpUpmH9+KT6q506OTDYohAe+6e9KCZE9Ku5T17/pEnC /NEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@samsung.com header.s=mail20170921 header.b="P/nxsA/e"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=samsung.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p13si2361004ejb.456.2020.10.21.18.58.39; Wed, 21 Oct 2020 18:59:01 -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; dkim=pass header.i=@samsung.com header.s=mail20170921 header.b="P/nxsA/e"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=samsung.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2442433AbgJUODA (ORCPT + 99 others); Wed, 21 Oct 2020 10:03:00 -0400 Received: from mailout3.samsung.com ([203.254.224.33]:34691 "EHLO mailout3.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2408608AbgJUOC7 (ORCPT ); Wed, 21 Oct 2020 10:02:59 -0400 Received: from epcas5p3.samsung.com (unknown [182.195.41.41]) by mailout3.samsung.com (KnoxPortal) with ESMTP id 20201021140256epoutp0368509d80ae891a5d4031b5cba8a8efe8~ABtR27zAE2978529785epoutp038 for ; Wed, 21 Oct 2020 14:02:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout3.samsung.com 20201021140256epoutp0368509d80ae891a5d4031b5cba8a8efe8~ABtR27zAE2978529785epoutp038 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1603288976; bh=wjrduFjgfm07XfY7v3+tVmfXvRbDBj4UbIFGVRu6kkY=; h=Subject:Reply-To:From:To:CC:In-Reply-To:Date:References:From; b=P/nxsA/evQv0kqawzDi0Iiz4l3B+QnYCGioCxJQ1cgLaSAzPImyICyZNjYxiVvD79 ec1COVIfx+Gh7oVRT6VfKqFrZsMcetEH1iboc4LCwGaWLcwUg8ucRg3IRGfi5OfatR Qd6iNYZU3OWgq1s/anXgUA0dPlvv6R3FBsCeHL6c= Received: from epsmges5p1new.samsung.com (unknown [182.195.42.73]) by epcas5p3.samsung.com (KnoxPortal) with ESMTP id 20201021140255epcas5p3a587675a2c3fad3a63f603f1660cabbe~ABtQpT7xu1056910569epcas5p3r; Wed, 21 Oct 2020 14:02:55 +0000 (GMT) X-AuditID: b6c32a49-a67ff70000002565-79-5f903f8fbc04 Received: from epcas5p2.samsung.com ( [182.195.41.40]) by epsmges5p1new.samsung.com (Symantec Messaging Gateway) with SMTP id D1.42.09573.F8F309F5; Wed, 21 Oct 2020 23:02:55 +0900 (KST) Mime-Version: 1.0 Subject: RE: [PATCH 2/3] arm: introduce IRQ stacks Reply-To: v.narang@samsung.com Sender: Vaneet Narang From: Vaneet Narang To: Russell King - ARM Linux admin , Arnd Bergmann CC: AMIT SAHRAWAT , Andrew Morton , Marc Zyngier , Sebastian Andrzej Siewior , Vincent Whitchurch , Nick Desaulniers , "linux-kernel@vger.kernel.org" , Valentin Schneider , Dmitry Safonov <0x7f454c46@gmail.com>, Maninder Singh , Thomas Gleixner , Nathan Huckleberry , Will Deacon , Jian Cai , Linux ARM X-Priority: 3 X-Content-Kind-Code: NORMAL In-Reply-To: <20201021125740.GM1551@shell.armlinux.org.uk> X-Drm-Type: N,general X-Msg-Generator: Mail X-Msg-Type: PERSONAL X-Reply-Demand: N Message-ID: <20201021134653epcms5p7a6932d1304c604b224a04025c6f0153e@epcms5p7> Date: Wed, 21 Oct 2020 19:16:53 +0530 X-CMS-MailID: 20201021134653epcms5p7a6932d1304c604b224a04025c6f0153e Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Sendblock-Type: REQ_APPROVE CMS-TYPE: 105P X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFKsWRmVeSWpSXmKPExsWy7bCmhm6//YR4g1MTZC0mTHvBYnFxd6rF nPVr2Cy2bdnEajHt4iRmi5XzdjJabHp8jdXi8q45bBaHpu5ltDg8v43FYueck6wWHyb8Z7LY fPgTi8XmTVOZLbbP/8lscX6bv0XLHVMHQY8189Ywely+dpHZ4/q6AI+ds+6yeyzYVOqxaVUn m8e7c+fYPU7M+M3isXlJvUffllWMHp83yQVwR3HZpKTmZJalFunbJXBlTLg8mb1gqUDF4UdN LA2MM3m7GDk5JARMJO5eO8LcxcjFISSwm1Fix7nPTF2MHBy8AoISf3cIg9QICxhJfOhaygpi CwnISRy/sZsRIq4jcQLoLJByNgEtiY8t4SBhEYFYiR9djewgI5kFprJKvPg9lx1iF6/EjPan LBC2tMT25VvB5nAKWEl83LSKFSIuKnFz9Vt2GPv9sfmMELaIROu9s8wQtqDEg5+7oeIyEt+/ 9rOCLJMQ6GaU+Lyljw3CmcIoMfv3aSaIKnOJ3RvmsUA85itxro8DJMwioCox9+16qMUuElPv HAZbzCwgL7H97RxmkHJmAU2J9bv0IUpkJaaeWscEUcIn0fv7CRPMXzvmwdhKEucO7mSDsCUk nnTOhLrZQ2LRhDms0HBmljg8/z77BEaFWYignoVk8yyEzQsYmVcxSqYWFOempxabFhjmpZbr FSfmFpfmpesl5+duYgQnPy3PHYx3H3zQO8TIxMF4iFGCg1lJhDdPdEK8EG9KYmVValF+fFFp TmrxIUZpDhYlcV6lH2fihATSE0tSs1NTC1KLYLJMHJxSDUw213m5MlIS92ycZGByiSn3U9+C hKYaj2n3QoJjt2dHyve3GJ5auOJR1x+OZ50x3m9M156Qs5rmfi32pdinyQLH5a6e+/B9qeSL ncmdcSckG178vnl7Rc3Ro8E73sh8tNx7eMPShXuimBZNvulhwnj2MD/70+ebhYNPuN13l3g9 07rXf2v/a/kalhMLNrJVf5v7TuDI9uSpfDMXael13KnyTLeXEbTr0HBf/sfKqe5vucVt7TQL m5KGrF1KvkYrXhjxBK4o/TbryoJPz+QnG0Sku/x9Ib15hUlHyOzzfw7cCBHdph73n71NZ0/F nu0dUdo1H45rTTF/NHUeTzRXRxT7xjP+8yVSfXJj+a341loqsRRnJBpqMRcVJwIAobyHZ+0D AAA= X-CMS-RootMailID: 20201008071639epcas5p465f13d992a25936ba63436baf1fb6f83 References: <20201021125740.GM1551@shell.armlinux.org.uk> <1602141333-17822-1-git-send-email-maninder1.s@samsung.com> <1602141333-17822-3-git-send-email-maninder1.s@samsung.com> <20201021124542.GL1551@shell.armlinux.org.uk> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Russel & Arnd, > > > - define 'current' as 'this_cpu_read_stable(current_task);' > > > - convert to CONFIG_THREAD_INFO_IN_TASK > unlike ARM64 ARM doesn't suport dedicated register like "sp_el0", so arm still stores thread info on stack and fetches using current task using stack pointer (SP) so CONFIG_THREAD_INFO_IN_TASK is not supported on ARM. To implement solution inline with current ARM design, we have used indirection. > That means we need to also code that up in assembly - remember, we > need to access thread_info from assembly code. > Note also that there is a circular dependency involved. If you make > thread_info accessible via per-cpu, then: > "We don't do it because we don't have a separate register to be able > to store the thread_info pointer, and copying that lump between the > SVC and IRQ stack will add massively to IRQ latency, especially for > older machines." We tried to minimize latency in switching between SVC stack and IRQ stack by just copying extra thread info pointer to IRQ stack. Apart from this, Most of the code of SVC to IRQ switching is similar to ARM64 implementation. Also We tried to minimize latency of get_current() by introducting self pointer in SVC stack to avoid if check to determine, is current is called from SVC context or IRQ context. This way will always do one extra indirection in get_current, irrespective get_current is called from SVC or IRQ context. Yes we agree still there will be minor additional latency on accessing current task and SVC to IRQ switching which might be significant for older machines, So this is the reason why we kept this sol. under kconfig. This solution provides extra stack to kernel developers for further development,instead of increasing stack size to 16KB or spending time on debugging stack overflow issues. PS: We have debugged and resolved stack overflow issue but we still implemented this sol. to avoid debugging such issues in future also it gives us flexibility for kernel enhancement on ARM. Thanks & Regards, Vaneet Narang