Date: Tue, 18 Jul 2000 21:09:36 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: Alfred Perlstein <bright@wintelcom.net> Cc: David Malone <dwmalone@maths.tcd.ie>, freebsd-bugs@freebsd.org, iedowse@maths.tcd.ie, sheldonh@freebsd.org, jlemon@freebsd.org, wollman@freebsd.org Subject: Re: kern/19866: The mbuf subsystem refcount stuff. Message-ID: <Pine.BSF.4.21.0007182059540.37767-100000@jehovah.technokratis.com> In-Reply-To: <20000718160033.H13979@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 18 Jul 2000, Alfred Perlstein wrote:
> That never happens. If you have an mbuf it's _yours_ no one will
> deref it out from under you otherwise it wouldn't work at all. You
> can NOT pass an mbuf you some subsystem and then free it, you must
> pass a _copy_ of it if you want to use it again later (attach
> another mbuf header and increase the ref count), therefor the
> refcount will be 1 higher and even if it's free()'d at intr you'll
> never go to 0.
Alfred, it's not the MBUF that is being referenced, it's the ext_buf
attached to the m_ext of the mbuf, which CAN be referenced by multiple
mbufs. The idea is to have the referencing handled by the mbuf because a
single mbuf can only map ONE external object.
> The reason is to hopefully avoid locking the entire pool or locking
> 3 objects to make a single cluster copy. I'm not saying that you
> have to make 3 locks, but I can't see it any other way:
> myself, backward, forward -> manip pointers
By that logic you're going to have to make per CPU pools and add many
more hysterics to the system. This is not even the beginning of your
problems if your plan is to re-invent the wheel. But if you do plan to do
that, count on me to help you if you request it in the future, however,
don't avoid new things from going in because of it. :-)
> Actually, I would like to see it go in, the macro approach will
> make it easy to move it over the pointer to refcount memory idea,
> I'd just hoped that you would have done it my way. Your work
> will take us halfway there and be very benificial in the meanwhile
> by reducing the amount of callbacks needed when sending clusters
> as well as simplifying a lot of code and special cases.
If you have an alternate suggestion that is different than the
existing one (i.e. get absolutely rid of that mclrefcnt global array),
that will WORK, and that is better than what I just proposed (which is
actually taken from NetBSD in part), then I'm all ears and ready to
implement! (By know, you know that I have no problem writing code for
the project)
> Lastly, I'd like to apologize for my behavior on IRC, it was uncalled
> for, this is some highly needed and quality work and I wanted to
> thank you for taking the time to do it.
It's all good. I've done my share of bad attitude as well. I
just have to point out that your input *is* important and valued and that
even though I dispute it (vehemently, at times), I hope that you can see
that it is clearly backed by [relatively] valid arguments, and reasonably
within context. I guess I'm also somewhat frustrated due to the multiple
changes that I have been having to make and the general holdup that I've
experienced. But, I'll deal. :-)
> --
> -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
> "I have the heart of a child; I keep it in a jar on my desk."
Regards,
Bosko.
--
Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237
bmilekic@technokratis.com * http://www.technokratis.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" 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.0007182059540.37767-100000>