Re: [RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib

[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 ?

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/