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-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
