It is a principal objective of IRQ stack feature to reduce kernel
stack size. Therefore, the size is set to 8KB when a separate IRQ
stack is active.
Signed-off-by: Jungseok Lee
---
arch/arm64/include/asm/thread_info.h | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64
On 07/04/14 14:27, Arnd Bergmann wrote:
> On Friday 04 July 2014 11:13:31 Andrey Ryabinin wrote:
>>>
>>> but I wonder if there is a way to avoid the extra include here, as it might
>>> also
>>> cause a general slowdown because of asm/memory.h getting pulled into more .c
>>> files. Would it be reas
On Friday 04 July 2014 11:13:31 Andrey Ryabinin wrote:
> >
> > but I wonder if there is a way to avoid the extra include here, as it might
> > also
> > cause a general slowdown because of asm/memory.h getting pulled into more .c
> > files. Would it be reasonable to hardcode PAGE_SIZE here?
> >
>
On 07/04/14 00:24, Arnd Bergmann wrote:
> On Wednesday 18 June 2014, Andrey Ryabinin wrote:
>> diff --git a/arch/arm/include/asm/thread_info.h
>> b/arch/arm/include/asm/thread_info.h
>> index f989d7c..f85d2b0 100644
>> --- a/arch/arm/include/asm/thread_info.h
>> +++ b/arch/arm/include/asm/thread_i
On Wednesday 18 June 2014, Andrey Ryabinin wrote:
> diff --git a/arch/arm/include/asm/thread_info.h
> b/arch/arm/include/asm/thread_info.h
> index f989d7c..f85d2b0 100644
> --- a/arch/arm/include/asm/thread_info.h
> +++ b/arch/arm/include/asm/thread_info.h
> @@ -14,9 +14,10 @@
>
> #include
>
On 06/18/14 18:40, Nicolas Pitre wrote:
> On Wed, 18 Jun 2014, Andrey Ryabinin wrote:
>
>> Changing kernel stack size on arm is not as simple as it should be:
>> 1) THRED_SIZE macro doen't respect PAGE_SIZE and THREAD_SIZE_ORDER
>> 2) stack size is hardcoded in get
On 06/18/14 18:31, Will Deacon wrote:
> On Wed, Jun 18, 2014 at 02:50:22PM +0100, Andrey Ryabinin wrote:
>> Changing kernel stack size on arm is not as simple as it should be:
>> 1) THRED_SIZE macro doen't respect PAGE_SIZE and THREAD_SIZE_ORDER
>
> THREAD_SIZE
>
On Wed, 18 Jun 2014, Andrey Ryabinin wrote:
> Changing kernel stack size on arm is not as simple as it should be:
> 1) THRED_SIZE macro doen't respect PAGE_SIZE and THREAD_SIZE_ORDER
> 2) stack size is hardcoded in get_thread_info macro
>
> This patch fixes it by cacula
On Wed, Jun 18, 2014 at 02:50:22PM +0100, Andrey Ryabinin wrote:
> Changing kernel stack size on arm is not as simple as it should be:
> 1) THRED_SIZE macro doen't respect PAGE_SIZE and THREAD_SIZE_ORDER
THREAD_SIZE
> 2) stack size is hardcoded in get_thread_info macro
>
>
Changing kernel stack size on arm is not as simple as it should be:
1) THRED_SIZE macro doen't respect PAGE_SIZE and THREAD_SIZE_ORDER
2) stack size is hardcoded in get_thread_info macro
This patch fixes it by caculating THREAD_SIZE and thread_info address
taking into account PAGE_SIZ
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Feng Kan
commit 845ad05ec31e0f3872a321e10dbeaf872022632c upstream.
Written by Catalin Marinas, tested by APM on storm platform. This is needed
because of the failures encountered when running
iscussed in
> http://lists.linuxfoundation.org/pipermail/bridge/2005-January/004402.html
>
> Is it OK the double the x86_64 kernel stack size?
>
Hell no.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger
double the x86_64 kernel stack size?
Signed-off-by: Zhouyi Zhou
Tested-by: Zhouyi Zhou
---
arch/x86/include/asm/page_64_types.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/page_64_types.h
b/arch/x86/include/asm/page_64_types.h
index 43dcd80
On Wed, 6 Jun 2007 11:11:34 -0400 Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 05, 2007 at 06:20:24PM -0700, Andrew Morton wrote:
> > If you do
> >
> > - int "Kernel stack size order"
> > + int
> >
> > then this rule wi
On Tue, Jun 05, 2007 at 06:20:24PM -0700, Andrew Morton wrote:
> If you do
>
> - int "Kernel stack size order"
> + int
>
> then this rule will no longer be offered to the user and `make oldconfig'
> (actually anythingconfig) will override wha
learn enough for the problem at hand, then instaforget it
again. Kinda like perl.
> but what I have is
>
> config KERNEL_STACK_ORDER
> int "Kernel stack size order"
> default 1 if 64BIT
> default 0 if !64BIT
>
> which seems reasonably clear an
onfig, breaking UML/x86_64, which wants 2 page stacks.
> That means the Kconfig rules are wrong, surely?
I'm far from a Kconfig expert, but what I have is
config KERNEL_STACK_ORDER
int "Kernel stack size order"
default 1 if 64BIT
def
On Tue, 5 Jun 2007 16:50:55 -0400
Jeff Dike <[EMAIL PROTECTED]> wrote:
> [ This is 2.6.22 material ]
>
> Having KERNEL_STACK_ORDER in defconfig overrides the value provided by
> Kconfig, breaking UML/x86_64, which wants 2 page stacks.
>
> Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
> --
> arch
[ This is 2.6.22 material ]
Having KERNEL_STACK_ORDER in defconfig overrides the value provided by
Kconfig, breaking UML/x86_64, which wants 2 page stacks.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/defconfig |1 -
1 file changed, 1 deletion(-)
Index: linux-2.6.21-mm/arch/um/de
Steven Rostedt wrote:
On Sun, 2005-04-03 at 09:10 +0200, Manfred Spraul wrote:
Yes - sem or spin locks are quicker as long as no cache line transfers
are necessary. If the semaphore is accessed by multiple cpus, then
kmalloc would be faster: slab tries hard to avoid taking global locks.
I'm n
On Sun, 2005-04-03 at 09:10 +0200, Manfred Spraul wrote:
> Yes - sem or spin locks are quicker as long as no cache line transfers
> are necessary. If the semaphore is accessed by multiple cpus, then
> kmalloc would be faster: slab tries hard to avoid taking global locks.
> I'm not speaking abou
Steven Rostedt wrote:
Have you benchmarked your own memory manager?
kmalloc(1024, GFP_KERNEL) is something like 17 instructions on i386
uniprocessor.
Where did you get that? I'm looking at the assembly of it right now and
it's much larger than 17 instructions. Not to mention that it calls the
On Sat, 2005-04-02 at 22:14 +0200, Manfred Spraul wrote:
> Steven Rostedt wrote:
>
> >I admit you really need to know what you're doing to use this method. If
> >I believe that a kmalloc would be too expensive, then I use the locking
> >of static variables. But each situation is different and I tr
Steven Rostedt wrote:
I admit you really need to know what you're doing to use this method. If
I believe that a kmalloc would be too expensive, then I use the locking
of static variables. But each situation is different and I try to use
the best method for the occasion.
Have you benchmarked your
On Sat, 2005-04-02 at 20:37 +0100, Al Viro wrote:
> On Sat, Apr 02, 2005 at 02:04:11PM -0500, Steven Rostedt wrote:
> > You can also use globally static variables too. But this makes for
> > non-reentry code.
> >
> > Sometimes I don't feel that a kmalloc is worth it, and if the function
> > in que
On Sat, Apr 02, 2005 at 02:04:11PM -0500, Steven Rostedt wrote:
> You can also use globally static variables too. But this makes for
> non-reentry code.
>
> Sometimes I don't feel that a kmalloc is worth it, and if the function
> in question for the driver would seldom have problems with reentry,
On Sun, 2005-04-03 at 03:48 +0900, ooyama eiichi wrote:
> > > because my driver hungs the machine by an certain ioctl. and it
> > > seems to me there is no bad in the code correspond to the ioctl,
> > > except for that it is using large auto variables. (some functions
> > > are useing ~1KB autos
> On Sun, Apr 03, 2005 at 03:15:42AM +0900, ooyama eiichi wrote:
>
> > in i386 and ia64.
>
> search for CONFIG_DEBUG_STACKOVERFLOW in arch/i386/kernel/irq.c
Oh, very good information for me.
>
> ia64 has fairly large stacks so you probably won't need to check there
> if you get the above worki
ooyama eiichi wrote:
Thanks for your reply.
On Sun, Apr 03, 2005 at 02:46:34AM +0900, ooyama eiichi wrote:
How can I know the rest size of the kernel stack.
you can't in a platfork-independant way
in i386 and ia64.
(in my kernel driver)
*why* do you want to do this?
because my driver hungs the
On Sun, Apr 03, 2005 at 03:15:42AM +0900, ooyama eiichi wrote:
> in i386 and ia64.
search for CONFIG_DEBUG_STACKOVERFLOW in arch/i386/kernel/irq.c
ia64 has fairly large stacks so you probably won't need to check there
if you get the above working
> because my driver hungs the machine by an cert
Thanks for your reply.
> On Sun, Apr 03, 2005 at 02:46:34AM +0900, ooyama eiichi wrote:
>
> > How can I know the rest size of the kernel stack.
>
> you can't in a platfork-independant way
in i386 and ia64.
>
> > (in my kernel driver)
>
> *why* do you want to do this?
>
because my driver hu
On Sun, Apr 03, 2005 at 02:46:34AM +0900, ooyama eiichi wrote:
> How can I know the rest size of the kernel stack.
you can't in a platfork-independant way
> (in my kernel driver)
*why* do you want to do this?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Hi all,
How can I know the rest size of the kernel stack.
(in my kernel driver)
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
entry.S
> 2. I've often heard that the kernel stack size is set small (4 or 8k?). Is
> this done by limiting the size of the stack segment itself for the kernel?
> Where is the code which sets up the limit?
The stack segment is a flat segment just like the code and data
segments.
.) in sys.c,
but where is the code which userland calls to transfer to "kernel mode" and
execute a particular syscall?
2. I've often heard that the kernel stack size is set small (4 or 8k?). Is
this done by limiting the size of the stack segment itself for the kernel?
Where is the co
35 matches
Mail list logo
