Date: Sun, 15 Sep 2013 19:30:41 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Davide Italiano <davide@freebsd.org> Cc: jeff@FreeBSD.org, dtrace@freebsd.org Subject: Re: vmem(9) use in Dtrace Message-ID: <52365131.8020709@FreeBSD.org> In-Reply-To: <CACYV=-H42pN2TXAp6vCjWRH=8g9Ttpzcex1RPd1Unj1oZWeRGg@mail.gmail.com> References: <52360A3E.40804@FreeBSD.org> <CACYV=-H42pN2TXAp6vCjWRH=8g9Ttpzcex1RPd1Unj1oZWeRGg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15/09/2013 2:53 p. m., Davide Italiano wrote: > On Sun, Sep 15, 2013 at 9:27 PM, Pedro Giffuni <pfg@freebsd.org> wrote: >> Hi; >> >> Just noticed this, in the old DtraceTODO wiki: >> >> https://wiki.freebsd.org/DTraceTODO >> >> There is mention of some use that Dtrace makes of Solaris's vmem >> allocator, specifically vmem_create(), vmem_destroy(), vmem_alloc(), and >> vmem_free(). These functions (not exact but similar ones) have >> been brought to FreeBSD 10 (r252330). >> >> According to opengrok we may just have to uncomment some Solaris >> code in sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c >> > > We need also to provide at least some sort of wrappers for e.g. flags > passed to vmem_alloc which takes VM_SLEEP in solaris while in FreeBSD > this is M_WAITOK etc... > >> This would reduce differences with the Solaris code but it has >> to be examined carefully as I think John Birrell had already >> solved the issue by providing the resource id's natively (kmem). >> >> Just thought I would point it out ... It may be that it is not >> worth spending too much time on it since the existing code should >> just work. >> > > vmem is designed to be a generic resource allocator. I still need to > analyze how Dtrace uses it but in general it provides better > scalability and less fragmentation wrt home-rolled allocators we have > in the kernel. FWIW, Illumos uses it for several things, e.g. pid/tid > allocation. It might worth a try. > FWIW, the next point in the old DTrace TODO list is that Solaris has vmem_cache_*. Maybe providing a cache is something that may be useful in FreeBSD too. Regards, Pedro.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52365131.8020709>