Re: [RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib
On Fri, 17 Apr 2015, Richard Weinberger wrote: > SLUB is the unqueued SLAB and SLLB is the library SLAB. :D Good that this convention is now so broadly known that I did not even have to explain what it meant. But I think you can give it any name you want. SLLB was just a way to tersely state how this is going to integrate into the overall scheme of things. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib
At Fri, 17 Apr 2015 17:08:22 +0200, Richard Weinberger wrote: > add header includion for CONFIG_LIB to wrap kmalloc and co. This will > bring malloc(3) based allocator used by arch/lib. > >>> > >>> Maybe add another allocator insteadl? SLLB which implements memory > >>> management using malloc()? > >> > >> Yeah, that's a good idea. > > > > first, my bad, I should be more precise on the commit message. > > > > the patch with 04/11 patch is used _not_ only malloc(3) but > > also any allocator registered by our entry API, lib_init(). > > > > for NUSE case, we use malloc(3) but for DCE (ns-3) case, we > > use our own allocator, which manages the (virtual) process > > running on network simulator. > > > > if these externally configurable memory allocator are point > > of interest in Linux kernel, maybe adding another allocator > > into mm/ is interesting but I'm not sure. what do you think ? > > This is the idea behind SLLB. > > > btw, what does stand for SLLB ? (just curious) > > SLUB is the unqueued SLAB and SLLB is the library SLAB. :D thanks. I will be back with SLLB and give v3 patches soon. -- Hajime -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib
Am 17.04.2015 um 17:02 schrieb Hajime Tazaki: > > Hi Christoph, Richard, > > At Fri, 17 Apr 2015 14:44:35 +0200, > Richard Weinberger wrote: >> >> Am 17.04.2015 um 14:17 schrieb Christoph Lameter: >>> On Fri, 17 Apr 2015, Hajime Tazaki wrote: >>> add header includion for CONFIG_LIB to wrap kmalloc and co. This will bring malloc(3) based allocator used by arch/lib. >>> >>> Maybe add another allocator insteadl? SLLB which implements memory >>> management using malloc()? >> >> Yeah, that's a good idea. > > first, my bad, I should be more precise on the commit message. > > the patch with 04/11 patch is used _not_ only malloc(3) but > also any allocator registered by our entry API, lib_init(). > > for NUSE case, we use malloc(3) but for DCE (ns-3) case, we > use our own allocator, which manages the (virtual) process > running on network simulator. > > if these externally configurable memory allocator are point > of interest in Linux kernel, maybe adding another allocator > into mm/ is interesting but I'm not sure. what do you think ? This is the idea behind SLLB. > btw, what does stand for SLLB ? (just curious) SLUB is the unqueued SLAB and SLLB is the library SLAB. :D >> Hajime, another question, do you really want a malloc/free backend? >> I'm not a mm expert, but does malloc() behave exactly as the kernel >> counter parts? > > as stated above, A1) yes, we need our own allocator, and A2) > yes as NUSE proofed, it behaves fine. Okay. >> In UML we allocate a big file on the host side, mmap() it and give this >> mapping >> to the kernel as physical memory such that any kernel allocator can work >> with it. > > libos doesn't virtualize a physical memory but provide > allocator functions returning memory block on a request > instead. Makes sense. I thought maybe it can help you reducing the code footprint. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib
Hi Christoph, Richard, At Fri, 17 Apr 2015 14:44:35 +0200, Richard Weinberger wrote: > > Am 17.04.2015 um 14:17 schrieb Christoph Lameter: > > On Fri, 17 Apr 2015, Hajime Tazaki wrote: > > > >> add header includion for CONFIG_LIB to wrap kmalloc and co. This will > >> bring malloc(3) based allocator used by arch/lib. > > > > Maybe add another allocator insteadl? SLLB which implements memory > > management using malloc()? > > Yeah, that's a good idea. first, my bad, I should be more precise on the commit message. the patch with 04/11 patch is used _not_ only malloc(3) but also any allocator registered by our entry API, lib_init(). for NUSE case, we use malloc(3) but for DCE (ns-3) case, we use our own allocator, which manages the (virtual) process running on network simulator. if these externally configurable memory allocator are point of interest in Linux kernel, maybe adding another allocator into mm/ is interesting but I'm not sure. what do you think ? btw, what does stand for SLLB ? (just curious) > Hajime, another question, do you really want a malloc/free backend? > I'm not a mm expert, but does malloc() behave exactly as the kernel > counter parts? as stated above, A1) yes, we need our own allocator, and A2) yes as NUSE proofed, it behaves fine. > In UML we allocate a big file on the host side, mmap() it and give this > mapping > to the kernel as physical memory such that any kernel allocator can work with > it. libos doesn't virtualize a physical memory but provide allocator functions returning memory block on a request instead. -- Hajime -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib
Am 17.04.2015 um 14:17 schrieb Christoph Lameter: > On Fri, 17 Apr 2015, Hajime Tazaki wrote: > >> add header includion for CONFIG_LIB to wrap kmalloc and co. This will >> bring malloc(3) based allocator used by arch/lib. > > Maybe add another allocator insteadl? SLLB which implements memory > management using malloc()? Yeah, that's a good idea. Hajime, another question, do you really want a malloc/free backend? I'm not a mm expert, but does malloc() behave exactly as the kernel counter parts? In UML we allocate a big file on the host side, mmap() it and give this mapping to the kernel as physical memory such that any kernel allocator can work with it. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib
On Fri, 17 Apr 2015, Hajime Tazaki wrote: > add header includion for CONFIG_LIB to wrap kmalloc and co. This will > bring malloc(3) based allocator used by arch/lib. Maybe add another allocator insteadl? SLLB which implements memory management using malloc()? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib
add header includion for CONFIG_LIB to wrap kmalloc and co. This will
bring malloc(3) based allocator used by arch/lib.
Signed-off-by: Hajime Tazaki
---
include/linux/slab.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 9a139b6..6914e1f 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -205,6 +205,14 @@ size_t ksize(const void *);
#endif
#endif
+#ifdef CONFIG_LIB
+#define KMALLOC_SHIFT_MAX 30
+#define KMALLOC_SHIFT_HIGH PAGE_SHIFT
+#ifndef KMALLOC_SHIFT_LOW
+#define KMALLOC_SHIFT_LOW 3
+#endif
+#endif
+
/* Maximum allocatable size */
#define KMALLOC_MAX_SIZE (1UL << KMALLOC_SHIFT_MAX)
/* Maximum size for which we actually use a slab cache */
@@ -350,6 +358,9 @@ kmalloc_order_trace(size_t size, gfp_t flags, unsigned int
order)
}
#endif
+#ifdef CONFIG_LIB
+#include
+#else
static __always_inline void *kmalloc_large(size_t size, gfp_t flags)
{
unsigned int order = get_order(size);
@@ -428,6 +439,7 @@ static __always_inline void *kmalloc(size_t size, gfp_t
flags)
}
return __kmalloc(size, flags);
}
+#endif
/*
* Determine size used for the nth kmalloc cache.
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib
add header includion for CONFIG_LIB to wrap kmalloc and co. This will
bring malloc(3) based allocator used by arch/lib.
Signed-off-by: Hajime Tazaki taz...@sfc.wide.ad.jp
---
include/linux/slab.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 9a139b6..6914e1f 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -205,6 +205,14 @@ size_t ksize(const void *);
#endif
#endif
+#ifdef CONFIG_LIB
+#define KMALLOC_SHIFT_MAX 30
+#define KMALLOC_SHIFT_HIGH PAGE_SHIFT
+#ifndef KMALLOC_SHIFT_LOW
+#define KMALLOC_SHIFT_LOW 3
+#endif
+#endif
+
/* Maximum allocatable size */
#define KMALLOC_MAX_SIZE (1UL KMALLOC_SHIFT_MAX)
/* Maximum size for which we actually use a slab cache */
@@ -350,6 +358,9 @@ kmalloc_order_trace(size_t size, gfp_t flags, unsigned int
order)
}
#endif
+#ifdef CONFIG_LIB
+#include asm/slab.h
+#else
static __always_inline void *kmalloc_large(size_t size, gfp_t flags)
{
unsigned int order = get_order(size);
@@ -428,6 +439,7 @@ static __always_inline void *kmalloc(size_t size, gfp_t
flags)
}
return __kmalloc(size, flags);
}
+#endif
/*
* Determine size used for the nth kmalloc cache.
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib
On Fri, 17 Apr 2015, Hajime Tazaki wrote: add header includion for CONFIG_LIB to wrap kmalloc and co. This will bring malloc(3) based allocator used by arch/lib. Maybe add another allocator insteadl? SLLB which implements memory management using malloc()? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib
Am 17.04.2015 um 14:17 schrieb Christoph Lameter: On Fri, 17 Apr 2015, Hajime Tazaki wrote: add header includion for CONFIG_LIB to wrap kmalloc and co. This will bring malloc(3) based allocator used by arch/lib. Maybe add another allocator insteadl? SLLB which implements memory management using malloc()? Yeah, that's a good idea. Hajime, another question, do you really want a malloc/free backend? I'm not a mm expert, but does malloc() behave exactly as the kernel counter parts? In UML we allocate a big file on the host side, mmap() it and give this mapping to the kernel as physical memory such that any kernel allocator can work with it. Thanks, //richard -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib
Hi Christoph, Richard, At Fri, 17 Apr 2015 14:44:35 +0200, Richard Weinberger wrote: Am 17.04.2015 um 14:17 schrieb Christoph Lameter: On Fri, 17 Apr 2015, Hajime Tazaki wrote: add header includion for CONFIG_LIB to wrap kmalloc and co. This will bring malloc(3) based allocator used by arch/lib. Maybe add another allocator insteadl? SLLB which implements memory management using malloc()? Yeah, that's a good idea. first, my bad, I should be more precise on the commit message. the patch with 04/11 patch is used _not_ only malloc(3) but also any allocator registered by our entry API, lib_init(). for NUSE case, we use malloc(3) but for DCE (ns-3) case, we use our own allocator, which manages the (virtual) process running on network simulator. if these externally configurable memory allocator are point of interest in Linux kernel, maybe adding another allocator into mm/ is interesting but I'm not sure. what do you think ? btw, what does stand for SLLB ? (just curious) Hajime, another question, do you really want a malloc/free backend? I'm not a mm expert, but does malloc() behave exactly as the kernel counter parts? as stated above, A1) yes, we need our own allocator, and A2) yes as NUSE proofed, it behaves fine. In UML we allocate a big file on the host side, mmap() it and give this mapping to the kernel as physical memory such that any kernel allocator can work with it. libos doesn't virtualize a physical memory but provide allocator functions returning memory block on a request instead. -- Hajime -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib
Am 17.04.2015 um 17:02 schrieb Hajime Tazaki: Hi Christoph, Richard, At Fri, 17 Apr 2015 14:44:35 +0200, Richard Weinberger wrote: Am 17.04.2015 um 14:17 schrieb Christoph Lameter: On Fri, 17 Apr 2015, Hajime Tazaki wrote: add header includion for CONFIG_LIB to wrap kmalloc and co. This will bring malloc(3) based allocator used by arch/lib. Maybe add another allocator insteadl? SLLB which implements memory management using malloc()? Yeah, that's a good idea. first, my bad, I should be more precise on the commit message. the patch with 04/11 patch is used _not_ only malloc(3) but also any allocator registered by our entry API, lib_init(). for NUSE case, we use malloc(3) but for DCE (ns-3) case, we use our own allocator, which manages the (virtual) process running on network simulator. if these externally configurable memory allocator are point of interest in Linux kernel, maybe adding another allocator into mm/ is interesting but I'm not sure. what do you think ? This is the idea behind SLLB. btw, what does stand for SLLB ? (just curious) SLUB is the unqueued SLAB and SLLB is the library SLAB. :D Hajime, another question, do you really want a malloc/free backend? I'm not a mm expert, but does malloc() behave exactly as the kernel counter parts? as stated above, A1) yes, we need our own allocator, and A2) yes as NUSE proofed, it behaves fine. Okay. In UML we allocate a big file on the host side, mmap() it and give this mapping to the kernel as physical memory such that any kernel allocator can work with it. libos doesn't virtualize a physical memory but provide allocator functions returning memory block on a request instead. Makes sense. I thought maybe it can help you reducing the code footprint. Thanks, //richard -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib
At Fri, 17 Apr 2015 17:08:22 +0200, Richard Weinberger wrote: add header includion for CONFIG_LIB to wrap kmalloc and co. This will bring malloc(3) based allocator used by arch/lib. Maybe add another allocator insteadl? SLLB which implements memory management using malloc()? Yeah, that's a good idea. first, my bad, I should be more precise on the commit message. the patch with 04/11 patch is used _not_ only malloc(3) but also any allocator registered by our entry API, lib_init(). for NUSE case, we use malloc(3) but for DCE (ns-3) case, we use our own allocator, which manages the (virtual) process running on network simulator. if these externally configurable memory allocator are point of interest in Linux kernel, maybe adding another allocator into mm/ is interesting but I'm not sure. what do you think ? This is the idea behind SLLB. btw, what does stand for SLLB ? (just curious) SLUB is the unqueued SLAB and SLLB is the library SLAB. :D thanks. I will be back with SLLB and give v3 patches soon. -- Hajime -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib
On Fri, 17 Apr 2015, Richard Weinberger wrote: SLUB is the unqueued SLAB and SLLB is the library SLAB. :D Good that this convention is now so broadly known that I did not even have to explain what it meant. But I think you can give it any name you want. SLLB was just a way to tersely state how this is going to integrate into the overall scheme of things. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
