Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp69167imu; Thu, 15 Nov 2018 22:16:31 -0800 (PST) X-Google-Smtp-Source: AJdET5d7qCOl7qhet+VfIEUfWjpLtQvZIktOaqQkCfVWK2WQaWvwEily3+ycspY7AGQOp8I9S5Yk X-Received: by 2002:a63:3f44:: with SMTP id m65mr8994601pga.115.1542348991146; Thu, 15 Nov 2018 22:16:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542348991; cv=none; d=google.com; s=arc-20160816; b=PV8GejZ0tA/9eyVff3Wu8l0Kfr8N7iB+LfIbnfGfug1eUdOkn+1LgGBQwmQCHkT7Fm Dju1MVUx9rUG36oJyj4hnKelPkVCgQd1Qcp8WRup8/kuS+DkhTks1tQcoveSGWKhljy/ YxDebTN13i3V4UzXIFOUvpFpMTT93D24fk+HFiiNIiuVF9cE7vX2sFNjIr98zJPUONiv p5vESM1pGFIPelX0r294nVknDAygy1/tLTg1jOOv5CCxcQQbh7wS15jaL4WTeLUVhuVX AIwCUwApwrddqaWTlzdPCWUGU1jRdZEsEMZK4S2jamoym4AwGQtmurpAcOdq5KpIGMSB CVoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=jzdSF647iqbefNCVxiSvHUbwkyyYuEACtF2iDJpNIzg=; b=VJpoMSSRoP+QtMuyzn9M7FhdbQOmRCgHUQam/ye9uzPs4elvpR3OmmomDCAs41RAbX dQCy+ZlIzR5T2oZRlYoVOsmHr9Rgebum68Y1/zJcoaHdmcOJDZBsjtXtAzQKIttyVyl8 x4WK5wZEid0jydEc5LQgsgzHLAmb3XaXkZXT+MpL0LgFpO5sFhLd2dp+fgOsfKE4Pm4f 3MYvKplLMZJS9AB+bR8Z6NgGkPyGf31WHhtzLnEGB+szAo7U7evvI7fHyhfWkmqL4410 gQTXZ5ogXIyWdNRk7X/Z9++lHyyPhzPICzD9ZKi/I0OOBiI4fjM8EdsCRdvpG/Ir/YnV inXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Q4cbMOcp; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b19si4561252pfm.100.2018.11.15.22.16.02; Thu, 15 Nov 2018 22:16:31 -0800 (PST) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Q4cbMOcp; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389154AbeKPQZu (ORCPT + 99 others); Fri, 16 Nov 2018 11:25:50 -0500 Received: from mail-ua1-f45.google.com ([209.85.222.45]:33517 "EHLO mail-ua1-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727353AbeKPQZu (ORCPT ); Fri, 16 Nov 2018 11:25:50 -0500 Received: by mail-ua1-f45.google.com with SMTP id t8so191213uap.0 for ; Thu, 15 Nov 2018 22:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jzdSF647iqbefNCVxiSvHUbwkyyYuEACtF2iDJpNIzg=; b=Q4cbMOcpQSnJQyPBldPIgg9QcgtZtqMzo+xXh4sUxer66LJlYegphoNxRxypICVUY0 OSTe72kelWwN5cPpjfl2NAO2DOyarXq8hqL+MOiP+VLLDky5+sYjeI0B4MfDPN7MhiXq qWxZI3KcXEN5qWjkrKke4K0zpbyhhyTEjayldcaLhPjwSSVbYi3nDOhjohQKZZCCO2jz 8YA4St4SWkgUjfKyFOk9803gy8HWe/GJW04zbHL4GeAhz63RyuBm01/WIwpsW8a4DOZJ 1hJ+pg6LINMWnwLHtqDGSXS0I5nNuv9hrrdLdKNqp3+BgrXYqrrNZMr7ztIwtyQzCOrN pRYw== 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=jzdSF647iqbefNCVxiSvHUbwkyyYuEACtF2iDJpNIzg=; b=pzkwmmJy3a7Nt2OgDJsgtZmBtcd9CkefOurWyo9eUqCtpahf7GoYQu+OdP5GejePdY /9OKxP89z7CkUx4g2Qv0lQhzcPI+Pfu17g+EfimrDDrHsBHumpqLlURLMa2bKROOFOjj 3469g3Uhy4n0qwP3uXR0CillHTy9wkgzvPLyHKiu7XF3QswN0TVnQrsBswXuPkOUP6A2 NntgOrpA2/DwPZLl50IUtf0p7gTh8BvsBXW2d6+74mRQpwSpGd762mumeXR4YzYWOAgu 6uh/ovPW8jintWFDBdyGSTw2lx9+AOzRm9c/pongu3tlLOQbySflaCZdMasAbXo24ktg u0PQ== X-Gm-Message-State: AGRZ1gJpB0s6WsdMVdt5X37JE5gcCOK19K6XmTwvO6CwIA+K+gjUbtWv mLVQ5lulhBxHTizSSutG1Kv4zq5tSfZWHKZdCMY= X-Received: by 2002:ab0:8d9:: with SMTP id o25mr4300110uaf.127.1542348888362; Thu, 15 Nov 2018 22:14:48 -0800 (PST) MIME-Version: 1.0 References: <28496.1542300549@turing-police.cc.vt.edu> In-Reply-To: <28496.1542300549@turing-police.cc.vt.edu> From: Pintu Agarwal Date: Fri, 16 Nov 2018 11:44:36 +0530 Message-ID: Subject: Re: [ARM64] Printing IRQ stack usage information To: Valdis Kletnieks Cc: open list , linux-arm-kernel@lists.infradead.org, Russell King - ARM Linux , kernelnewbies@kernelnewbies.org, Jungseok Lee , catalin.marinas@arm.com, will.deacon@arm.com, Takahiro Akashi , mark.rutland@arm.com, Sungjinn Chung Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 15 Nov 2018, 10:19 pm > On Thu, 15 Nov 2018 18:52:39 +0530, Pintu Agarwal said: > > > Currently, when I tested this (as a proc interface), I got the below output: > > CPU UNUSED-STACK ACTUAL-STACK > > 0 16368 16384 > > > 3) How should I test it to get the different usage values for unused stack ? > > Can I get these values by implementing a sample interrupt handler, > > and printing information from there? > > Hint 1: If you're in a state where seq_printf() is legal, how many IRQ's are > on this processor's IRQ stack? > > Hint 2: What are the chances that some other CPU is currently in an IRQ? > (run 'top' and look for what percent of time that's happening) > > Hint 3: what are the chances that the value of irq_stack_ptr is already stale > by the time seq_printf() finishes running? > > Hint 4: what happens to the validity of your output if you get rescheduled > in the middle of that for_each loop? > > (In other words, this code is terribly racy and is probably not going to answer > whatever debugging question you were working on.. Okay. Thanks so much for your hints. Yes, I understand that this code is horribly ugly and bad. But this is only to understand if the below logic is fine to get the irq stack usage: {{{ for_each_present_cpu(cpu) { irq_stack_ptr = IRQ_STACK_PTR(cpu); //unsigned long sp = current_stack_pointer; stack_start = (unsigned long)per_cpu(irq_stack, cpu); free_stack = irq_stack_ptr - stack_start; seq_printf(m, "%2d %10lu %10d\n", cpu, free_stack, actual); } }}} Of course, final plan is not the proc entry, but to find a relevant place to invoke it, probably during boot time, or during backtrace. > If your question is "Did one > of the CPUs blow out its IRQ stack (or come close to doing so)?" there's better > approaches. > Yes, exactly, this is what the main intention. If you have any better idea about this approach, please refer me. It will be of great help. Thank You! >