From: Jungseok Lee <jungseoklee85@gmail.com> To: Catalin Marinas <catalin.marinas@arm.com> Cc: James Morse <james.morse@arm.com>, mark.rutland@arm.com, barami97@gmail.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, takahiro.akashi@linaro.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v4 2/2] arm64: Expand the stack trace feature to support IRQ stack Date: Sat, 17 Oct 2015 22:38:16 +0900 [thread overview] Message-ID: <3AD5938C-4109-4B95-A13B-5D45525B39FB@gmail.com> (raw) In-Reply-To: <20151016160606.GE6613@e104818-lin.cambridge.arm.com> On Oct 17, 2015, at 1:06 AM, Catalin Marinas wrote: Hi Catalin, > On Fri, Oct 16, 2015 at 10:01:20PM +0900, Jungseok Lee wrote: >> On Oct 16, 2015, at 12:59 AM, James Morse wrote: >>> My concern is there could be push-back from the maintainer of >>> kernel/fork.c, saying "define CONFIG_ARCH_THREAD_INFO_ALLOCATOR if the >>> generic code isn't what you need", and push-back from the arm64 maintainers >>> about copy-pasting that chunk into arch/arm64.... both of which are fair, >>> hence my initial version created a second kmem_cache. >> >> Same concern. I believe now is the time to get feedbacks from maintainers. >> It will help us to decide the next step. > > I'll push back now to avoid further doubts in changing kernel/fork.c ;). Thanks a lot! > A reason to define a kmem_cache is performance for repeated allocations. > But here you only do it once during boot. So you could simply use > kmalloc() when THREAD_SIZE < PAGE_SIZE. BTW, the IRQ stack size doesn't > even need to be the same as THREAD_SIZE, though we could initially keep > them the same. But it's worth defining an IRQ_STACK_SIZE macro if we > ever need to change it. I will update the series using IRQ_* macro. > BTW, a static allocation (DEFINE_PER_CPU for the whole irq stack) would > save us from another stack address reading on the IRQ entry path. I'm > not sure exactly where the 16K image increase comes from but at least it > doesn't grow with NR_CPUS, so we can probably live with this. I've tried the approach, a static allocation using DEFINE_PER_CPU, but it dose not work on a top-bit comparison method (for IRQ re-entrance check). The top-bit idea is based on the assumption that IRQ stack is aligned with THREAD_SIZE. But, tpidr_el1 is PAGE_SIZE aligned. It leads to IRQ re-entrance failure in case of 4KB page system. IMHO, it is hard to avoid 16KB size increase for 64KB page support. Secondary cores can rely on slab.h, but a boot core cannot. So, IRQ stack for at least a boot cpu should be allocated statically. Best Regards Jungseok Lee
WARNING: multiple messages have this Message-ID (diff)
From: jungseoklee85@gmail.com (Jungseok Lee) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v4 2/2] arm64: Expand the stack trace feature to support IRQ stack Date: Sat, 17 Oct 2015 22:38:16 +0900 [thread overview] Message-ID: <3AD5938C-4109-4B95-A13B-5D45525B39FB@gmail.com> (raw) In-Reply-To: <20151016160606.GE6613@e104818-lin.cambridge.arm.com> On Oct 17, 2015, at 1:06 AM, Catalin Marinas wrote: Hi Catalin, > On Fri, Oct 16, 2015 at 10:01:20PM +0900, Jungseok Lee wrote: >> On Oct 16, 2015, at 12:59 AM, James Morse wrote: >>> My concern is there could be push-back from the maintainer of >>> kernel/fork.c, saying "define CONFIG_ARCH_THREAD_INFO_ALLOCATOR if the >>> generic code isn't what you need", and push-back from the arm64 maintainers >>> about copy-pasting that chunk into arch/arm64.... both of which are fair, >>> hence my initial version created a second kmem_cache. >> >> Same concern. I believe now is the time to get feedbacks from maintainers. >> It will help us to decide the next step. > > I'll push back now to avoid further doubts in changing kernel/fork.c ;). Thanks a lot! > A reason to define a kmem_cache is performance for repeated allocations. > But here you only do it once during boot. So you could simply use > kmalloc() when THREAD_SIZE < PAGE_SIZE. BTW, the IRQ stack size doesn't > even need to be the same as THREAD_SIZE, though we could initially keep > them the same. But it's worth defining an IRQ_STACK_SIZE macro if we > ever need to change it. I will update the series using IRQ_* macro. > BTW, a static allocation (DEFINE_PER_CPU for the whole irq stack) would > save us from another stack address reading on the IRQ entry path. I'm > not sure exactly where the 16K image increase comes from but at least it > doesn't grow with NR_CPUS, so we can probably live with this. I've tried the approach, a static allocation using DEFINE_PER_CPU, but it dose not work on a top-bit comparison method (for IRQ re-entrance check). The top-bit idea is based on the assumption that IRQ stack is aligned with THREAD_SIZE. But, tpidr_el1 is PAGE_SIZE aligned. It leads to IRQ re-entrance failure in case of 4KB page system. IMHO, it is hard to avoid 16KB size increase for 64KB page support. Secondary cores can rely on slab.h, but a boot core cannot. So, IRQ stack for at least a boot cpu should be allocated statically. Best Regards Jungseok Lee
next prev parent reply other threads:[~2015-10-17 13:38 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-10-07 15:28 [PATCH v4 0/2] arm64: Introduce IRQ stack Jungseok Lee 2015-10-07 15:28 ` Jungseok Lee 2015-10-07 15:28 ` [PATCH v4 1/2] " Jungseok Lee 2015-10-07 15:28 ` Jungseok Lee 2015-10-08 10:25 ` Pratyush Anand 2015-10-08 10:25 ` Pratyush Anand 2015-10-08 14:32 ` Jungseok Lee 2015-10-08 14:32 ` Jungseok Lee 2015-10-08 16:51 ` Pratyush Anand 2015-10-08 16:51 ` Pratyush Anand 2015-10-07 15:28 ` [PATCH v4 2/2] arm64: Expand the stack trace feature to support " Jungseok Lee 2015-10-07 15:28 ` Jungseok Lee 2015-10-09 14:24 ` James Morse 2015-10-09 14:24 ` James Morse 2015-10-12 14:53 ` Jungseok Lee 2015-10-12 14:53 ` Jungseok Lee 2015-10-12 16:34 ` James Morse 2015-10-12 16:34 ` James Morse 2015-10-12 22:13 ` Jungseok Lee 2015-10-12 22:13 ` Jungseok Lee 2015-10-13 11:00 ` James Morse 2015-10-13 11:00 ` James Morse 2015-10-13 15:00 ` Jungseok Lee 2015-10-13 15:00 ` Jungseok Lee 2015-10-14 12:12 ` Jungseok Lee 2015-10-14 12:12 ` Jungseok Lee 2015-10-15 15:59 ` James Morse 2015-10-15 15:59 ` James Morse 2015-10-16 13:01 ` Jungseok Lee 2015-10-16 13:01 ` Jungseok Lee 2015-10-16 16:06 ` Catalin Marinas 2015-10-16 16:06 ` Catalin Marinas 2015-10-17 13:38 ` Jungseok Lee [this message] 2015-10-17 13:38 ` Jungseok Lee 2015-10-19 16:18 ` Catalin Marinas 2015-10-19 16:18 ` Catalin Marinas 2015-10-20 13:08 ` Jungseok Lee 2015-10-20 13:08 ` Jungseok Lee 2015-10-21 15:14 ` Jungseok Lee 2015-10-21 15:14 ` Jungseok Lee 2015-10-14 7:13 ` AKASHI Takahiro 2015-10-14 7:13 ` AKASHI Takahiro 2015-10-14 12:24 ` Jungseok Lee 2015-10-14 12:24 ` Jungseok Lee 2015-10-14 12:55 ` Jungseok Lee 2015-10-14 12:55 ` Jungseok Lee 2015-10-15 4:19 ` AKASHI Takahiro 2015-10-15 4:19 ` AKASHI Takahiro 2015-10-15 13:39 ` Jungseok Lee 2015-10-15 13:39 ` Jungseok Lee 2015-10-19 6:47 ` AKASHI Takahiro 2015-10-19 6:47 ` AKASHI Takahiro 2015-10-20 13:19 ` Jungseok Lee 2015-10-20 13:19 ` Jungseok Lee 2015-10-15 14:24 ` Jungseok Lee 2015-10-15 14:24 ` Jungseok Lee 2015-10-15 16:01 ` James Morse 2015-10-15 16:01 ` James Morse 2015-10-16 13:02 ` Jungseok Lee 2015-10-16 13:02 ` Jungseok Lee
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3AD5938C-4109-4B95-A13B-5D45525B39FB@gmail.com \ --to=jungseoklee85@gmail.com \ --cc=barami97@gmail.com \ --cc=catalin.marinas@arm.com \ --cc=james.morse@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=takahiro.akashi@linaro.org \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.