Date: Wed, 27 Feb 2002 12:49:45 -0500 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Jeff Roberson <jroberson@chesapeake.net> Cc: arch@FreeBSD.ORG Subject: Re: Slab allocator Message-ID: <20020227124945.A29065@unixdaemons.com> In-Reply-To: <20020227005915.C17591-100000@mail.chesapeake.net>; from jroberson@chesapeake.net on Wed, Feb 27, 2002 at 02:03:39AM -0500 References: <20020227005915.C17591-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 27, 2002 at 02:03:39AM -0500, Jeff Roberson wrote: [...] > There are two things that I would really like comments on. > > 1) Should I keep the uma_ prefixes on exported functions/types. Yes, I believe that this is generally good practise. > 2) How much of the malloc_type stats should I keep? They either require > atomic ops or a lock in their current state. Also, non power of two > malloc sizes breaks their usage tracking. I suggest that you re-do the stats based on uma, and not based on exactly what malloc exported. Try to group most of the stat modifications (writes) under some existing lock, if that's possible. If not, please don't add another lock just for those stats. I don't think that any statistics should require a lock just to be read (via sysctl()). > 3) Should I rename the files to vm_zone.c vm_zone.h, etc? I think you shouldn't. :-) We shouldn't confuse uma with our old vm_zone. > Since you've read this far, I'll let you know where the patch is. ;-) > > http://www.chesapeake.net/~jroberson/uma.tar > > This includes a patch to the base system that converts several previous > vm_zone users to uma users, and it also provides a vm_zone wrapper for > those that haven't been converted. I did this to minimize the diffs so it > would be easier to review. This also has vm/uma* which you need to > extract into your sys/ directory. > > Any feedback is appreciated. I'd like to know what people expect from > this before it is committable. After looking over it, I think that: (i) This allocator should go into -CURRENT (ii) For what concerns malloc and vm_zone, I suggest that they still live in -CURRENT for the next couple of months (since you've already instrumented them to wrap to uma in your patch). I sugest that a sysctl knob determines whether or not malloc and vm_zone allocation calls wrap to uma or call their old selves. This should allow us to quickly switch back and forth for the next couple of months, and it will probably also minimize conflicts for those maintaining large patch sets (*ducks* :-)). (iii) For what concerns mbuf allocations, I don't know what to tell you right now. Ultimately, I would like to see uma eventually replace mb_alloc. However, I would like to make sure that the transition is smooth and painless and that we don't lose any performance. This is why I think that co-existing uma with all existing code (see (ii)) is a good idea. Then, if you're willing, I would be glad to help "attach" mbuf allocations to uma, should that be possible and should we decide, as a group, that that is what we want to do. > Jeff > > PS Sorry for the long winded email. :-) Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020227124945.A29065>