Date: Fri, 31 May 2002 09:16:51 -0400 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Peter Wemm <peter@wemm.org>, Richard Wenninger <richard@richardw.net>, current@FreeBSD.ORG Subject: Re: UMA lock Message-ID: <20020531091651.A69469@unixdaemons.com> In-Reply-To: <3CF73C23.A8491DC2@mindspring.com>; from tlambert2@mindspring.com on Fri, May 31, 2002 at 02:02:27AM -0700 References: <20020529061540.88CD6380A@overcee.wemm.org> <3CF475E3.8925781A@mindspring.com> <20020529091152.B61073@unixdaemons.com> <3CF53430.49B6F618@mindspring.com> <20020529162214.A62435@unixdaemons.com> <3CF73C23.A8491DC2@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 31, 2002 at 02:02:27AM -0700, Terry Lambert wrote: [...] > Bottom line? > > I'd like to see one set of uniform semantics. > > It really disturbs me that the behaviour of a common flag changes > for some code, because of a sysctl, but doesn't change for all code > using the flag. > > I'd also like to see one set of code, if it can be negotiated between > you and the SLAB allocator guy. N allocators is usually N-1 too many, > IMO. Yes, it was my intention to co-ordinate with JeffR and perhaps in a year from now (once UMA really stabilizes and I get the current backlog in my TODO well, out of the backlog) to take a stab at having the mbuf code use uma for allocations. This is why I delayed any further design work in mb_alloc for the moment. I agree that having fewer allocators is a Good Thing and have considered this with the Good of the Project in mind (as opposed to personal issues, ego, or whatever). :-) In any case, when the time comes to really tackle the issue, we will have to be very very careful. mb_alloc was written in such a way that mbuf allocations are optimized out and that for all common-case allocations, ONE function call is performed for the allocation, not more. I remember initially getting a very hard time from you and the lists on keeping the performance numbers up for mbuf allocations (we are known for having very fast mbuf allocation) and I also recall many nights of performance measurement and data gathering. My observation was that: 1) Getting rid of the large macros and moving to mb_alloc, even with Giant in place, slightly improved overall speed (I still have the data, actually: http://www.freebsd.org/~bmilekic/code/mb_alloc/results.html ) This is particularly the case for i386, where the negative cache effects of those large allocation/free macros was really noticable. 2) Increasing the common-case for allocations and frees to more than one single function call resulted in a noticable [albeit slight] slowdown, in the alpha in particular (unfortunately, something happened with jlemon's alpha stats so the graphs are no longer accessible). This is why I worked hard to place the allocation code in such a way to keep it at at most one function call for the common case. I'd like to maintain this assumption when/if we move to uma in the future. > -- Terry Cheers, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020531091651.A69469>