From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753834AbbIGQe1 (ORCPT ); Mon, 7 Sep 2015 12:34:27 -0400 Received: from mail-pa0-f41.google.com ([209.85.220.41]:35753 "EHLO mail-pa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753666AbbIGQeZ convert rfc822-to-8bit (ORCPT ); Mon, 7 Sep 2015 12:34:25 -0400 Subject: Re: [PATCH] arm64: kernel: Use a separate stack for irq interrupts. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Jungseok Lee In-Reply-To: <55EDB5FB.8060800@arm.com> Date: Tue, 8 Sep 2015 01:34:40 +0900 Cc: linux-arm-kernel@lists.infradead.org, "linux-kernel@vger.kernel.org Mailing List" , AKASHI Takahiro Content-Transfer-Encoding: 8BIT Message-Id: <81D7F9F1-1552-4709-BA74-1BF15163C4A0@gmail.com> References: <55EDA040.90208@arm.com> <1441636584-23174-1-git-send-email-james.morse@arm.com> <400272B6-0733-456F-95C9-9C72C597CEB5@gmail.com> <55EDB5FB.8060800@arm.com> To: James Morse X-Mailer: Apple Mail (2.1283) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sep 8, 2015, at 1:06 AM, James Morse wrote: > On 07/09/15 16:48, Jungseok Lee wrote: >> On Sep 7, 2015, at 11:36 PM, James Morse wrote: >> >> Hi James, >> >>> Having to handle interrupts on top of an existing kernel stack means the >>> kernel stack must be large enough to accomodate both the maximum kernel >>> usage, and the maximum irq handler usage. Switching to a different stack >>> when processing irqs allows us to make the stack size smaller. >>> >>> Maximum kernel stack usage (running ltp and generating usb+ethernet >>> interrupts) was 7256 bytes. With this patch, the same workload gives >>> a maximum stack usage of 5816 bytes. >> >> I'd like to know how to measure the max stack depth. >> AFAIK, a stack tracer on ftrace does not work well. Did you dump a stack >> region and find or track down an untouched region? > > I enabled the 'Trace max stack' option under menuconfig 'Kernel Hacking' -> > 'Tracers', then looked in debugfs:/tracing/stack_max_size. > > What problems did you encounter? > (I may be missing something…) When I enabled the feature, all entries had *0* size except the last entry. It can be reproduced easily as looking in debugs:/tracing/stack_trace. You can track down my report and Akashi's changes with the following links: - http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354126.html - https://lkml.org/lkml/2015/7/13/29 Although it is impossible to measure an exact depth at this moment, the feature could be utilized to check improvement. Cc'ing Akashi for additional comments if needed. Best Regards Jungseok Lee