Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1447355yba; Tue, 2 Apr 2019 09:03:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqxDswkqOZ8JtyjT1L2H0lHub6tUGa783xLDhoyE4vLkAAH0fD7mheX9uLVRgnvPotyBBnzF X-Received: by 2002:a62:604:: with SMTP id 4mr34316754pfg.38.1554220991680; Tue, 02 Apr 2019 09:03:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554220991; cv=none; d=google.com; s=arc-20160816; b=AbE5iP+PhnD9hewpdS/mutgNlE6TRaJs7ojxDtNnJJ/QNLujEZ2q6FwOzIkAYCamvP k5mPyudPHbhbI6GRznRs4sF+sMO55/gdjehmzgfMHY9pP1ThcK4RXF+NKDiljJuw0ECT 5X8D1sYWPIn+dNbU5BxBPqU9HIh0qM27St1jm/pSzXHjXKV8D607FOfSKrzvOFVjVtlW eY0ilXVaMrYEHY38kIUbRtTAJE0Mx4woyGbye31qTw4vrBRW561yyw0UirYT0eg+EPhE nYtYbjN/nHkJ2ySGYJzJDwL4ib45xpIr2x7dr2Anrr7dG4Be+GTMYdKafVDQLHDaPDP7 pxkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=pZOdn+HSUsW7tC/5pXn2KRCBD7rZR+w2ilat9ISDRkw=; b=dsXM0DuFLCQnwCS5tG444UtXhePszUM3aHWktYoAF8e3V7IfiRG8+1grNso1JAkDJW uZjPN6JL5ZVck88/e+98auUxbRhlPczM+/sdYtSpV2HrKtyMzX8GU/p8T916Mby+ZTO9 5V8hafE2mqzj1lc8rEM+mdvYO3bdQOmbvdMf95qaa14VFMsYIgdeuc4sWRDRUMxX27Fu pI9+yCQHUKILRb5tUBiTNrmQ3wZ8cm0Pm2FGC3G/eASkrKnTG44CyAB2mqSACWV67PtI AJGmY1pDg2rgGvvp/bQMzK/+kpR4BB7YfidBawp5j+DXAgaEUnnxQvp0ZZSJ0nuPwTo/ hKIA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r5si11164397pgp.29.2019.04.02.09.02.54; Tue, 02 Apr 2019 09:03:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731549AbfDBPtA (ORCPT + 99 others); Tue, 2 Apr 2019 11:49:00 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:37328 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728978AbfDBPtA (ORCPT ); Tue, 2 Apr 2019 11:49:00 -0400 Received: from [5.158.153.52] (helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hBLei-0003QC-Oh; Tue, 02 Apr 2019 17:48:56 +0200 Date: Tue, 2 Apr 2019 17:48:56 +0200 (CEST) From: Thomas Gleixner To: Josh Poimboeuf cc: LKML , x86@kernel.org, Andy Lutomirski Subject: Re: [patch 15/14] x86/dumpstack/64: Speedup in_exception_stack() In-Reply-To: <20190402154329.scp7i7uqevubgwrz@treble> Message-ID: References: <20190331214020.836098943@linutronix.de> <20190331215136.039902969@linutronix.de> <20190402154329.scp7i7uqevubgwrz@treble> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2 Apr 2019, Josh Poimboeuf wrote: > On Tue, Apr 02, 2019 at 12:19:46PM +0200, Thomas Gleixner wrote: > > +/* > > + * Array of exception stack page descriptors. If the stack is larger than > > + * PAGE_SIZE, all pages covering a particular stack will have the same > > + * info. > > + */ > > +static const struct estack_pages estack_pages[ESTACK_PAGES] ____cacheline_aligned = { > > + [CONDRANGE(DF)] = ESTACK_PAGE(DOUBLEFAULT_IST, DF), > > + [CONDRANGE(NMI)] = ESTACK_PAGE(NMI_IST, NMI), > > + [PAGERANGE(DB)] = ESTACK_PAGE(DEBUG_IST, DB), > > + [CONDRANGE(MCE)] = ESTACK_PAGE(MCE_IST, MCE), > > It would be nice if the *_IST macro naming aligned with the struct > cea_exception_stacks field naming. Then you could just do, e.g. > ESTACKPAGE(DF). Yes, lemme fix that up. > Also it's a bit unfortunate that some of the stack size knowledge is > hard-coded here, i.e #DB always being > 1 page and non-#DB being > sometimes 1 page. The problem is that there is no way to make this macro maze conditional on sizeof(). But my macro foo is rusty. > > + begin = (unsigned long)__this_cpu_read(cea_exception_stacks); > > + end = begin + sizeof(struct cea_exception_stacks); > > + /* Bail if @stack is outside the exception stack area. */ > > + if (stk <= begin || stk >= end) > > + return false; > > This check is the most important piece. Exception stack dumps are quite > rare, so this ensures an early exit in most cases regardless of whether > there's a loop below. > > > + > > + /* Calc page offset from start of exception stacks */ > > + k = (stk - begin) >> PAGE_SHIFT; > > + /* Lookup the page descriptor */ > > + ep = &estack_pages[k]; > > + /* Guard page? */ > > + if (unlikely(!ep->size)) > > + return false; > > + > > + begin += (unsigned long)ep->offs; > > + end = begin + (unsigned long)ep->size; > > + regs = (struct pt_regs *)end - 1; > > + > > + info->type = ep->type; > > + info->begin = (unsigned long *)begin; > > + info->end = (unsigned long *)end; > > + info->next_sp = (unsigned long *)regs->sp; > > + return true; > > With the above "(stk <= begin || stk >= end)" check, removing the loop > becomes not all that important since exception stack dumps are quite > rare and not performance sensitive. With all the macros this code > becomes a little more obtuse, so I'm not sure whether removal of the > loop is a net positive. What about perf? It's NMI context and probably starts from there. Peter? Thanks, tglx