Date: Wed, 04 Oct 2000 18:14:25 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: Julian Elischer <julian@elischer.org> Cc: net@FreeBSD.ORG Subject: Re: new mbuf stuff (dwmalone commit) Message-ID: <Pine.BSF.4.21.0010041753350.5631-100000@jehovah.technokratis.com> In-Reply-To: <39DB65A7.2FB8B884@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Oct 2000, Julian Elischer wrote: > The old code had two methods. > One to Add a reference and one to decrement a reference, > however the new code only leaves the code to decrement the reference. I'm not sure what you mean by this. It's still possible to add and remove references, it's just that now this is all done in the mbuf system code, and is much faster. If that is what you meant, then in that case, the "new code" doesn't leave "non-mbuf-system code" to decrement counters either; all it does is call the "non-mbuf-system code's" designated free routine when the counter [theoretically] reaches 0. > This means that code that supplies it's own external memory types > has no way to notify it's own memory manager that there are > multiple references to an object. That's correct. This behavior was discussed quite a bit on the lists before it was implemented. It was agreed on this way because, strictly speaking, the memory management code should not be concerned with the mbuf system's reference counters (under normal circumstances). > My guess is that it was assumed that the underlying memory manager > has no reason to know ho many references are held on an object, and that > there is now just a single reference from "the mbuf system" which is > removed > when the last mbuf internal reference is removed.. Right. > One system I know however had many objects, sorted in order of "number > of references" > in order to have the heavily used items near the head fo a list. Items > with only > one reference were "incomplete" and unlikely to be searched for. A system so closely tied to the mbuf system can theoretically still be modified to do this. All that is really required is that a pointer is held to the corresponding counter. The pointer can sit at the top of the buffer, for example (and m_data would have to be modified to point to top_of_buffer + sizeof (pointer)). If this is not desired, then you can always allocate/manage a separate data structure to hold this, and possibly other information about your buffer (note that you can easily have that structure passed to your free routine with the use of the extra pointer in the declaration of the free routine). Notice that with this suggestion, even though it may not seem so at a first glance, you'll still likely to have slightly better performance than before, because you don't have to deal with the relatively important overhead of calling an external function to do the job for you. The other advantage is that, if you have other places where you want this sort of behavior, you can re-use a large portion of the code that you'll write the first time, because it will always be dealing with the same identical type of counter data structure (in this case, a union). [...] > -- > __--_|\ Julian Elischer > / \ julian@elischer.org > ( OZ ) World tour 2000 > ---> X_.---._/ presently in: Perth > v Regards, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0010041753350.5631-100000>