From: Jungseok Lee <jungseoklee85@gmail.com> To: James Morse <james.morse@arm.com> Cc: takahiro.akashi@linaro.org, catalin.marinas@arm.com, will.deacon@arm.com, linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com, barami97@gmail.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 2/2] arm64: Expand the stack trace feature to support IRQ stack Date: Fri, 16 Oct 2015 22:01:20 +0900 [thread overview] Message-ID: <6E0DDC4D-9A97-4EAE-868C-B1271F02D3E0@gmail.com> (raw) In-Reply-To: <561FCD59.1090600@arm.com> On Oct 16, 2015, at 12:59 AM, James Morse wrote: Hi James, > On 14/10/15 13:12, Jungseok Lee wrote: >> On Oct 14, 2015, at 12:00 AM, Jungseok Lee wrote: >>> On Oct 13, 2015, at 8:00 PM, James Morse wrote: >>>> On 12/10/15 23:13, Jungseok Lee wrote: >>>>> On Oct 13, 2015, at 1:34 AM, James Morse wrote: >>>>>> Having two kmem_caches for 16K stacks on a 64K page system may be wasteful >>>>>> (especially for systems with few cpus)… >>>>> >>>>> This would be a single concern. To address this issue, I drop the 'static' >>>>> keyword in thread_info_cache. Please refer to the below hunk. >>>> >>>> Its only a problem on systems with 64K pages, which don't have a multiple >>>> of 4 cpus. I suspect if you turn on 64K pages, you have many cores with >>>> plenty of memory… >>> >>> Yes, the problem 'two kmem_caches' comes from only 64K page system. >>> >>> I don't get the statement 'which don't have a multiple of 4 cpus'. >>> Could you point out what I am missing? >> >> You're talking about sl{a|u}b allocator behavior. If so, I got what you meant. > > Yes, > With Nx4 cpus, the (currently) 16K irq stacks take up Nx64K - a nice > multiple of pages, so no wasted memory. > > >>>> If this has been made a published symbol, it should go in a header file. >>> >>> Sure. >> >> I had the wrong impression that there is a room under include/linux/*. > > Yes, I see there isn't anywhere obvious to put it... > > >> IMO, this is architectural option whether arch relies on thread_info_cache or not. >> In other words, it would be clear to put this extern under arch/*/include/asm/*. > > Its up to the arch whether or not to define > CONFIG_ARCH_THREAD_INFO_ALLOCATOR. In the case where it hasn't defined it, > and THREAD_SIZE >= PAGE_SIZE, your change is exposing thread_info_cache on > all architectures, so it ought go in a header file accessible to all > architectures. > > Something like this, (only build-tested!): > =========%<========= > --- a/include/linux/thread_info.h > +++ b/include/linux/thread_info.h > @@ -10,6 +10,8 @@ > #include <linux/types.h> > #include <linux/bug.h> > > +#include <asm/page.h> > + As reviewing arch codes, it seems not to cover all architecture.. > struct timespec; > struct compat_timespec; > > @@ -145,6 +147,12 @@ static inline bool test_and_clear_restore_sigmask(void) > #error "no set_restore_sigmask() provided and default one won't work" > #endif > > +#ifndef CONFIG_ARCH_THREAD_INFO_ALLOCATOR > +#if THREAD_SIZE >= PAGE_SIZE > +extern struct kmem_cache *thread_info_cache; > +#endif /* THREAD_SIZE >= PAGE_SIZE */ > +#endif /* CONFIG_ARCH_THREAD_INFO_ALLOCATOR */ > + > #endif /* __KERNEL__ */ > > #endif /* _LINUX_THREAD_INFO_H */ > =========%<========= > Quite ugly! > > 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 will do re-spin soon! 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: Fri, 16 Oct 2015 22:01:20 +0900 [thread overview] Message-ID: <6E0DDC4D-9A97-4EAE-868C-B1271F02D3E0@gmail.com> (raw) In-Reply-To: <561FCD59.1090600@arm.com> On Oct 16, 2015, at 12:59 AM, James Morse wrote: Hi James, > On 14/10/15 13:12, Jungseok Lee wrote: >> On Oct 14, 2015, at 12:00 AM, Jungseok Lee wrote: >>> On Oct 13, 2015, at 8:00 PM, James Morse wrote: >>>> On 12/10/15 23:13, Jungseok Lee wrote: >>>>> On Oct 13, 2015, at 1:34 AM, James Morse wrote: >>>>>> Having two kmem_caches for 16K stacks on a 64K page system may be wasteful >>>>>> (especially for systems with few cpus)? >>>>> >>>>> This would be a single concern. To address this issue, I drop the 'static' >>>>> keyword in thread_info_cache. Please refer to the below hunk. >>>> >>>> Its only a problem on systems with 64K pages, which don't have a multiple >>>> of 4 cpus. I suspect if you turn on 64K pages, you have many cores with >>>> plenty of memory? >>> >>> Yes, the problem 'two kmem_caches' comes from only 64K page system. >>> >>> I don't get the statement 'which don't have a multiple of 4 cpus'. >>> Could you point out what I am missing? >> >> You're talking about sl{a|u}b allocator behavior. If so, I got what you meant. > > Yes, > With Nx4 cpus, the (currently) 16K irq stacks take up Nx64K - a nice > multiple of pages, so no wasted memory. > > >>>> If this has been made a published symbol, it should go in a header file. >>> >>> Sure. >> >> I had the wrong impression that there is a room under include/linux/*. > > Yes, I see there isn't anywhere obvious to put it... > > >> IMO, this is architectural option whether arch relies on thread_info_cache or not. >> In other words, it would be clear to put this extern under arch/*/include/asm/*. > > Its up to the arch whether or not to define > CONFIG_ARCH_THREAD_INFO_ALLOCATOR. In the case where it hasn't defined it, > and THREAD_SIZE >= PAGE_SIZE, your change is exposing thread_info_cache on > all architectures, so it ought go in a header file accessible to all > architectures. > > Something like this, (only build-tested!): > =========%<========= > --- a/include/linux/thread_info.h > +++ b/include/linux/thread_info.h > @@ -10,6 +10,8 @@ > #include <linux/types.h> > #include <linux/bug.h> > > +#include <asm/page.h> > + As reviewing arch codes, it seems not to cover all architecture.. > struct timespec; > struct compat_timespec; > > @@ -145,6 +147,12 @@ static inline bool test_and_clear_restore_sigmask(void) > #error "no set_restore_sigmask() provided and default one won't work" > #endif > > +#ifndef CONFIG_ARCH_THREAD_INFO_ALLOCATOR > +#if THREAD_SIZE >= PAGE_SIZE > +extern struct kmem_cache *thread_info_cache; > +#endif /* THREAD_SIZE >= PAGE_SIZE */ > +#endif /* CONFIG_ARCH_THREAD_INFO_ALLOCATOR */ > + > #endif /* __KERNEL__ */ > > #endif /* _LINUX_THREAD_INFO_H */ > =========%<========= > Quite ugly! > > 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 will do re-spin soon! Best Regards Jungseok Lee
next prev parent reply other threads:[~2015-10-16 13:01 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 [this message] 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 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=6E0DDC4D-9A97-4EAE-868C-B1271F02D3E0@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.