Re: [QN/PATCH] Why do some archs allocate stack via kmalloc, others via get_free_pages?
Hi. On Fri, 2005-07-22 at 17:50, David S. Miller wrote: > From: Nigel Cunningham <[EMAIL PROTECTED]> > Date: Fri, 22 Jul 2005 14:11:17 +1000 > > > In making some modifications to Suspend, we've discovered that some > > arches use kmalloc and others use get_free_pages to allocate the stack. > > Is there a reason for the variation? If not, could the following patch > > be considered for inclusion (tested on x86 only). > > Some platforms really need it to be page aligned (sparc32 sun4c needs > to virtually map the resulting pages into a specific place, for > example). > > But, for the ones that don't have this requirement, they want the > cache coloring. Thanks David. Nigel -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities. - 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 http://www.tux.org/lkml/
Re: [QN/PATCH] Why do some archs allocate stack via kmalloc, others via get_free_pages?
From: Nigel Cunningham <[EMAIL PROTECTED]> Date: Fri, 22 Jul 2005 14:11:17 +1000 > In making some modifications to Suspend, we've discovered that some > arches use kmalloc and others use get_free_pages to allocate the stack. > Is there a reason for the variation? If not, could the following patch > be considered for inclusion (tested on x86 only). Some platforms really need it to be page aligned (sparc32 sun4c needs to virtually map the resulting pages into a specific place, for example). But, for the ones that don't have this requirement, they want the cache coloring. - 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 http://www.tux.org/lkml/
Re: [QN/PATCH] Why do some archs allocate stack via kmalloc, others via get_free_pages?
From: Nigel Cunningham [EMAIL PROTECTED] Date: Fri, 22 Jul 2005 14:11:17 +1000 In making some modifications to Suspend, we've discovered that some arches use kmalloc and others use get_free_pages to allocate the stack. Is there a reason for the variation? If not, could the following patch be considered for inclusion (tested on x86 only). Some platforms really need it to be page aligned (sparc32 sun4c needs to virtually map the resulting pages into a specific place, for example). But, for the ones that don't have this requirement, they want the cache coloring. - 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 http://www.tux.org/lkml/
Re: [QN/PATCH] Why do some archs allocate stack via kmalloc, others via get_free_pages?
Hi. On Fri, 2005-07-22 at 17:50, David S. Miller wrote: From: Nigel Cunningham [EMAIL PROTECTED] Date: Fri, 22 Jul 2005 14:11:17 +1000 In making some modifications to Suspend, we've discovered that some arches use kmalloc and others use get_free_pages to allocate the stack. Is there a reason for the variation? If not, could the following patch be considered for inclusion (tested on x86 only). Some platforms really need it to be page aligned (sparc32 sun4c needs to virtually map the resulting pages into a specific place, for example). But, for the ones that don't have this requirement, they want the cache coloring. Thanks David. Nigel -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities. - 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 http://www.tux.org/lkml/
[QN/PATCH] Why do some archs allocate stack via kmalloc, others via get_free_pages?
Hi all.
In making some modifications to Suspend, we've discovered that some
arches use kmalloc and others use get_free_pages to allocate the stack.
Is there a reason for the variation? If not, could the following patch
be considered for inclusion (tested on x86 only).
Regards,
Nigel
arch/frv/kernel/process.c |4 ++--
include/asm-frv/thread_info.h | 11 ---
include/asm-i386/thread_info.h | 11 ---
include/asm-m32r/thread_info.h | 10 +++---
include/asm-mips/thread_info.h |8 +---
include/asm-ppc64/thread_info.h |9 ++---
include/asm-um/thread_info.h|6 --
7 files changed, 40 insertions(+), 19 deletions(-)
diff -ruNp
821-make-task-struct-use-get-free-pages.patch-old/arch/frv/kernel/process.c
821-make-task-struct-use-get-free-pages.patch-new/arch/frv/kernel/process.c
--- 821-make-task-struct-use-get-free-pages.patch-old/arch/frv/kernel/process.c
2005-02-03 22:33:14.0 +1100
+++ 821-make-task-struct-use-get-free-pages.patch-new/arch/frv/kernel/process.c
2005-07-22 04:39:15.0 +1000
@@ -41,7 +41,7 @@ asmlinkage void ret_from_fork(void);
struct task_struct *alloc_task_struct(void)
{
- struct task_struct *p = kmalloc(THREAD_SIZE, GFP_KERNEL);
+ struct task_struct *p = (struct task_struct *)
__get_free_pages(GFP_KERNEL, THREAD_ORDER);
if (p)
atomic_set((atomic_t *)(p+1), 1);
return p;
@@ -50,7 +50,7 @@ struct task_struct *alloc_task_struct(vo
void free_task_struct(struct task_struct *p)
{
if (atomic_dec_and_test((atomic_t *)(p+1)))
- kfree(p);
+ free_pages((unsigned long) p, THREAD_ORDER);
}
static void core_sleep_idle(void)
diff -ruNp
821-make-task-struct-use-get-free-pages.patch-old/include/asm-frv/thread_info.h
821-make-task-struct-use-get-free-pages.patch-new/include/asm-frv/thread_info.h
---
821-make-task-struct-use-get-free-pages.patch-old/include/asm-frv/thread_info.h
2005-07-18 06:37:02.0 +1000
+++
821-make-task-struct-use-get-free-pages.patch-new/include/asm-frv/thread_info.h
2005-07-22 04:52:48.0 +1000
@@ -89,6 +89,8 @@ struct thread_info {
#define THREAD_SIZE8192
#endif
+#define THREAD_ORDER (THREAD_SIZE >> PAGE_SHIFT)
+
/* how to get the thread information struct from C */
register struct thread_info *__current_thread_info asm("gr15");
@@ -100,16 +102,19 @@ register struct thread_info *__current_t
({ \
struct thread_info *ret;\
\
- ret = kmalloc(THREAD_SIZE, GFP_KERNEL); \
+ ret = (struct thread_info *)\
+ __get_free_pages(GFP_KERNEL,\
+ THREAD_ORDER); \
if (ret)\
memset(ret, 0, THREAD_SIZE);\
ret;\
})
#else
-#define alloc_thread_info(tsk) kmalloc(THREAD_SIZE, GFP_KERNEL)
+#define alloc_thread_info(tsk) (struct thread_info *) \
+ __get_free_pages(GFP_KERNEL, THREAD_ORDER)
#endif
-#define free_thread_info(info) kfree(info)
+#define free_thread_info(info) free_pages((unsigned long) info, THREAD_ORDER)
#define get_thread_info(ti)get_task_struct((ti)->task)
#define put_thread_info(ti)put_task_struct((ti)->task)
diff -ruNp
821-make-task-struct-use-get-free-pages.patch-old/include/asm-i386/thread_info.h
821-make-task-struct-use-get-free-pages.patch-new/include/asm-i386/thread_info.h
---
821-make-task-struct-use-get-free-pages.patch-old/include/asm-i386/thread_info.h
2005-07-22 05:17:22.0 +1000
+++
821-make-task-struct-use-get-free-pages.patch-new/include/asm-i386/thread_info.h
2005-07-22 04:58:14.0 +1000
@@ -55,8 +55,10 @@ struct thread_info {
#define PREEMPT_ACTIVE 0x1000
#ifdef CONFIG_4KSTACKS
#define THREAD_SIZE(4096)
+#define THREAD_ORDER 0
#else
#define THREAD_SIZE(8192)
+#define THREAD_ORDER 1
#endif
#define STACK_WARN (THREAD_SIZE/8)
@@ -101,16 +103,19 @@ register unsigned long current_stack_poi
({ \
struct thread_info *ret;\
\
- ret = kmalloc(THREAD_SIZE, GFP_KERNEL); \
+ ret = (struct thread_info *)\
+ __get_free_pages(GFP_KERNEL,\
+ THREAD_ORDER); \
if (ret)\
memset(ret, 0, THREAD_SIZE);\
[QN/PATCH] Why do some archs allocate stack via kmalloc, others via get_free_pages?
Hi all.
In making some modifications to Suspend, we've discovered that some
arches use kmalloc and others use get_free_pages to allocate the stack.
Is there a reason for the variation? If not, could the following patch
be considered for inclusion (tested on x86 only).
Regards,
Nigel
arch/frv/kernel/process.c |4 ++--
include/asm-frv/thread_info.h | 11 ---
include/asm-i386/thread_info.h | 11 ---
include/asm-m32r/thread_info.h | 10 +++---
include/asm-mips/thread_info.h |8 +---
include/asm-ppc64/thread_info.h |9 ++---
include/asm-um/thread_info.h|6 --
7 files changed, 40 insertions(+), 19 deletions(-)
diff -ruNp
821-make-task-struct-use-get-free-pages.patch-old/arch/frv/kernel/process.c
821-make-task-struct-use-get-free-pages.patch-new/arch/frv/kernel/process.c
--- 821-make-task-struct-use-get-free-pages.patch-old/arch/frv/kernel/process.c
2005-02-03 22:33:14.0 +1100
+++ 821-make-task-struct-use-get-free-pages.patch-new/arch/frv/kernel/process.c
2005-07-22 04:39:15.0 +1000
@@ -41,7 +41,7 @@ asmlinkage void ret_from_fork(void);
struct task_struct *alloc_task_struct(void)
{
- struct task_struct *p = kmalloc(THREAD_SIZE, GFP_KERNEL);
+ struct task_struct *p = (struct task_struct *)
__get_free_pages(GFP_KERNEL, THREAD_ORDER);
if (p)
atomic_set((atomic_t *)(p+1), 1);
return p;
@@ -50,7 +50,7 @@ struct task_struct *alloc_task_struct(vo
void free_task_struct(struct task_struct *p)
{
if (atomic_dec_and_test((atomic_t *)(p+1)))
- kfree(p);
+ free_pages((unsigned long) p, THREAD_ORDER);
}
static void core_sleep_idle(void)
diff -ruNp
821-make-task-struct-use-get-free-pages.patch-old/include/asm-frv/thread_info.h
821-make-task-struct-use-get-free-pages.patch-new/include/asm-frv/thread_info.h
---
821-make-task-struct-use-get-free-pages.patch-old/include/asm-frv/thread_info.h
2005-07-18 06:37:02.0 +1000
+++
821-make-task-struct-use-get-free-pages.patch-new/include/asm-frv/thread_info.h
2005-07-22 04:52:48.0 +1000
@@ -89,6 +89,8 @@ struct thread_info {
#define THREAD_SIZE8192
#endif
+#define THREAD_ORDER (THREAD_SIZE PAGE_SHIFT)
+
/* how to get the thread information struct from C */
register struct thread_info *__current_thread_info asm(gr15);
@@ -100,16 +102,19 @@ register struct thread_info *__current_t
({ \
struct thread_info *ret;\
\
- ret = kmalloc(THREAD_SIZE, GFP_KERNEL); \
+ ret = (struct thread_info *)\
+ __get_free_pages(GFP_KERNEL,\
+ THREAD_ORDER); \
if (ret)\
memset(ret, 0, THREAD_SIZE);\
ret;\
})
#else
-#define alloc_thread_info(tsk) kmalloc(THREAD_SIZE, GFP_KERNEL)
+#define alloc_thread_info(tsk) (struct thread_info *) \
+ __get_free_pages(GFP_KERNEL, THREAD_ORDER)
#endif
-#define free_thread_info(info) kfree(info)
+#define free_thread_info(info) free_pages((unsigned long) info, THREAD_ORDER)
#define get_thread_info(ti)get_task_struct((ti)-task)
#define put_thread_info(ti)put_task_struct((ti)-task)
diff -ruNp
821-make-task-struct-use-get-free-pages.patch-old/include/asm-i386/thread_info.h
821-make-task-struct-use-get-free-pages.patch-new/include/asm-i386/thread_info.h
---
821-make-task-struct-use-get-free-pages.patch-old/include/asm-i386/thread_info.h
2005-07-22 05:17:22.0 +1000
+++
821-make-task-struct-use-get-free-pages.patch-new/include/asm-i386/thread_info.h
2005-07-22 04:58:14.0 +1000
@@ -55,8 +55,10 @@ struct thread_info {
#define PREEMPT_ACTIVE 0x1000
#ifdef CONFIG_4KSTACKS
#define THREAD_SIZE(4096)
+#define THREAD_ORDER 0
#else
#define THREAD_SIZE(8192)
+#define THREAD_ORDER 1
#endif
#define STACK_WARN (THREAD_SIZE/8)
@@ -101,16 +103,19 @@ register unsigned long current_stack_poi
({ \
struct thread_info *ret;\
\
- ret = kmalloc(THREAD_SIZE, GFP_KERNEL); \
+ ret = (struct thread_info *)\
+ __get_free_pages(GFP_KERNEL,\
+ THREAD_ORDER); \
if (ret)\
memset(ret, 0, THREAD_SIZE);\
