From owner-freebsd-hackers@freebsd.org Mon Mar 27 16:36:23 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F03FD204B9 for ; Mon, 27 Mar 2017 16:36:23 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F10EDB for ; Mon, 27 Mar 2017 16:36:23 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 7CA6A5A9F15; Mon, 27 Mar 2017 16:26:37 +0000 (UTC) Date: Mon, 27 Mar 2017 16:26:37 +0000 From: Brooks Davis To: Slawa Olhovchenkov Cc: Alexander Tarasikov , freebsd-hackers@freebsd.org Subject: Re: jmalloc in shared memory Message-ID: <20170327162637.GB59667@spindle.one-eyed-alien.net> References: <20170320131235.GB86500@zxy.spb.ru> <20170327135333.GD70430@zxy.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: <20170327135333.GD70430@zxy.spb.ru> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 16:36:23 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 27, 2017 at 04:53:33PM +0300, Slawa Olhovchenkov wrote: > On Mon, Mar 27, 2017 at 03:27:31PM +0200, Alexander Tarasikov wrote: >=20 > > Hi Slawa, > > I'm not sure jemalloc is supposed to be used this way, but you should > > be able to achieve this functionality in two ways: > > 1. Editing jemalloc's allocator ("src/pages.c") to allocate in your > > region instead of calling mmap() > > 2. Hook mmap() and brk(), sbrk() with LD_PRELOAD and provide > > implementations that will allocate in the shared memory > >=20 > > Hope this helps. >=20 > I am don't need to redirect ALL allocations in the shared memory. > I am need only do it for selected structures. > For example, I am need create red-black tree and update it (in shared > memory). For this, I am need create own memory management in this > region or use existing memory management tool (for allocate, > dealloacate and tracks chunks) worked for dedicated segment only. JEMalloc is almost certainly overkill for this application. It sounds likely you're allocating fixed sized objects (or at least not too many of them). For that, a simple slab allocator should do the trick. Alterntively, rtld contains a simple pooled malloc that's not hard to adapt to random backing stores (libexec/rtld-elf/malloc.c). I've got version adapted for CHERI with pluggable storage backends at https://github.com/CTSRD-CHERI/cheribsd/tree/master/lib/libmalloc_simple. It wouldn't be too hard turn it back into portable C. -- Brooks --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJY2T08AAoJEKzQXbSebgfAQJEIAIlsIw4RJmOAvYTQk4K5+rwS hSbCdySnQ46rlfHO5RKaVVklt4CF9Le4uxHYRUkPYttP7hzxebuulNN3nwK7CjEN GVlXX8RNmWfD5YeJTfpo93UPdArvooaMwGETtBUPWVdjxLEbWotb4RPsiRBXxA4Z F9JpLI/tcXnCWK4qaUR/Os1aZtZjfAGcavEvdmkZmGcu/cc++cw9X5zH3LSAaaUi tY3SLYws2ixptwzOhuliXV4voacOcDMvZN8W8a7d6Ug5J7F/pI0LJHt/5bGtx8J4 b59a+EnoGQRcou/yPt+v6zb0V4HKtTmpvdLEE7DsDJvsIT5wKVGjEaJl56RL8JE= =KqmF -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ--