Date: Fri, 21 Feb 2003 20:17:28 -0500 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Hiten Pandya <hiten@unixdaemons.com>, FreeBSD-arch@FreeBSD.ORG Subject: Re: Mbuf flags cleanup proposal Message-ID: <20030221201728.A80661@unixdaemons.com> In-Reply-To: <3E56B3F5.9EF3F9FE@mindspring.com>; from tlambert2@mindspring.com on Fri, Feb 21, 2003 at 03:19:17PM -0800 References: <20030221151007.GA60348@unixdaemons.com> <3E5673E7.F3F1FA4F@mindspring.com> <20030221150743.A79345@unixdaemons.com> <3E56B3F5.9EF3F9FE@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm not going to engage in a talk about integration and egalitarianism and whatever-else-you-feel-like-talking-about-today. You have some good ideas, you have some good experience, and I have seen some of good code of yours (admittedly, not recently, though). That still doesn't make you right about everything. In FreeBSD (notice I said "FreeBSD," not TerryBSD, SunOS, Linux, or whatever else), network buffer allocations have for the longest time been done seperately and for good enough reason; as a result, FreeBSD has adopted some fairly serious optimizations for what concerns the way they (and supporting structures) are allocated. "My" allocator (and by the way, it's wrong to call it _mine_ because it really is the result of a number of different people who have worked on it) maintains those optimizations (for lack of finding equally simple and well-performing replacements) while at the same time taking advantage of parallel processing in the kernel. Similarily, UMA is a great allocator, and it does similar things for general-purpose allocations in the system. If you ask me whether or not mbuf allocations can be made to use UMA? The answer is yes. If you ask me whether performance is going to be better? I don't know for sure, but I can tell you that in order to solve the issues I bring up it's going to be difficult, and I _do_ know that if you don't solve them, performance is going to suck, comparatively speaking. Solving them would require what I think is relatively serious modification to UMA which, in my opinion anyway, would uglify [sic] it. I *have* looked at it, and I think that the fact that UMA does allocations for all objects using the same techniques is great and - I can't speak for Jeff - but *I* wouldn't want to hack at it just so that we can get the optimizations/solutions we currently have for mbuf allocations. And, you know what? If *you* think it's worth it, why don't *YOU* do it and waste hours on end to, finally, get something that _maybe_ performs as well at the expense of an uglier (not-so-general-and-simple-anymore) allocator. On Fri, Feb 21, 2003 at 03:19:17PM -0800, Terry Lambert wrote: > Bosko Milekic wrote: > > > 1) This seems to move away from integration of UVA and the > > > mbuf allocator. > > > > You mean UMA. > > Yeah, UMA or whatever. > > > And this has absolutely nothing to do with it. There > > are several other reasons that the move is most likely not going to > > happen (they are cited at the top of the most recent subr_mbuf.c in > > the comments). I wish people read those more often and stopped > > blindly recommending where and to what things should move towards, > > without providing reasonable solutions to the problems that actually > > arise when TRYING to do what they suggest. In other words, talk is > > cheap, dirt cheap. > > You want the gloves off, we can take the gloves off. > > Let me point out that I did *not* participate in the discussion > where people were giving you crap for your hysteresis refill idea, > just because you failed to articulate the fact that the hysteresis > applied only to the garbage collection, and the people who were > giving you crap failed to read your code, and not your email. I'm > aware of the code, and what you failed to say about it, and what > the people condemning it failed to read about it. > > Let me also point out that I've avoided commenting on the use of > Horde-style algorithms in the code, once the project commited to > that path. So, in general, I don't comment on your mbuf allocator. > > Finally, let me point out that the idea of *not* integrating the > various allocators to a single, underlying allocation framework is > incredibly naieve. The Rodney King idea of "Can't we all just get > along?" is inherently bad. You cannot be egalitarian and let > everyone use whatever the hell model they want. That's what's wrong > with the whole FreeBSD SMP effort, which can't decide whether it's > locking code, critical paths, both, neither, and so you get these > massive, heavy-weight locking implementations that can't decide if > reentrancy is good, because it means you don't have to rewrite code, > or reentrancy is bad, because it means that code that needs to be > rewritten never is. > > > In other words, I know that people have been giving you some > unjustified crap about the code, and that my posting might > have looked enough like it that you gave a knee-jerk response. > > > With that in mind... > > Even if it's not your personal intent to address the interface > layering issues that prevent the code being integrated, it's a > bad idea to add yet-more-frobs to make the job harder for someone > twho *is* willing to do that scut work to do the integration at > some point in the future. > > This is a fundamental issue of project philosophy, and it should > *NOT* be decided by fiat, it should be decided by the project, as > a whole, or, minimally, the architecture board, whoever they are. > > > > > 2) It seems to me that all code should be moving to non-blocking > > > interfaces, and blocking interfaces should be deprecated. > > > > > > 3) "TRYWAIT" is really useless; either I can depend on blocking > > > until the request is satisfied, or I can't; if I can't, then > > > I might as well not have the extra complication of "wait a > > > little bit, and then fail anyway": it doesn't make my code > > > any less complicated. > > > > The behavior has absolutely nothing to do with your code. It's not an > > API thing, it's the default behavior of the allocator which tries to > > wait at least a little bit to see if it can recover during an > > exhaustion before giving up. I agree with you when you say that the > > networking code[1] should be taught to deal with failure (however > > "drastic" its dealing with it is is irrelevant), but that should not be > > sufficient reason to preclude the allocator from at least trying > > harder when it's in a tight spot. > > In for a penny, in for a pound... 8-(. > > I am fundamentally philosophically opposed to the idea of code > that will do it's best only if you ask it to, and by default will > only make a half-assed attempt, and in neither case is it willing > to commit to doing the job it claims it is capable of doing. > > An API is a *CONTRACT*. > > > I realize that the real reason this is there is that "TRYWAIT" > *really* means "It's OK to sleep, because we have a context on > which to sleep available to us", and the reason it's "TRYWAIT" > instead of "WAIT" is that what's *really* being said is "Wait > for resources, but in the absence of a working contention resolution > protocol in a low resource situation, try to fake one by backing > off, and hope that's good enough". > > > > [1] This is what I infer you're saying from this post and this > > earlier one: > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=333614+0+archive/2003/ \ > > freebsd-arch/20030126.freebsd-arch > > You need to reread the posting. It is *precisely*, to quote you, > > "sufficient reason to preclude the allocator from at least > trying harder when it's in a tight spot" > > There's no benefit to putting "try-to-worm-out-of-a-tight-spot" > code in every little subsystem. There should be a system-wide > strategy for "deal with being in a tight spot". > > This is morally equivalent "rape-proofing" a small section of the > sidewalk from the bus station to your house, and then claiming it's > now safe to walk home from the bus station. > > The literature, in general, tells us that the correct strategy is > "shed load"; that is, fail to service requests, and, if necessary, > indicate that failure to whoever cares enough that they will not > retry if not given an indicator. > > Further, it tells us to do this *as early as possible*, so that we > don't waste time partially processing a request that we will be > unable to complete processing on at the last minute. > > Djikstra called this the "Banker's Algorithm"; it has to do with > precommitting *all* resources, and if that can't be done, don't > *waste time* starting a job that can't be completed. > > > > As for the flags renaming, although I would like to see it, Sam made > > a good point in the first response to this post. Now let's just let > > it die and move on to bigger and better things. > > I'm all for renaming, if we don't care about integration at any > point in the future. You are claiming that we don't. If you are > right, then seperate the namespace overlap, and be done with it. > If not, bow to the pressure and admit that integration is a future > goal, rather than coming up with reasons why it's not possible to > do it, ever. > > Frankly, I think most of the contention is that people *want* > the integration, but you and Jeff are building your own little > kingdoms. What the rename amounts to, in that case, is that you > would like to build a fence, on the theory that "good fences make > good neighbors". > > I understand your arguments against integration, and I understand > *the* argument against integration: that you and Jeff would have to > hammer out a mutually acceptable philosophy, going forward, and > that that is volunteer work for which neither of you is willing to > volunteer, so it's not getting done. > > What I'm telling you is that the general population of the project > *wants* integration. The *do not* want to have to learn multiple > allocation API's to use in their code, and the *do not* want to > have to live with additional complexity tha makes it harder to > find someone maintain the code in the future, if you, Jeff, or both > get hit by a bus. In fact, if one of you *were* to get hit by a > bus, we would *definitely* end up getting the integration we want, > because the other code would rot for lack of a maintainer who has > bought into a general allocation philosophy held by the project. > > If you are going to build something, at least try to build something > that will outlive you; that's not possible in a vacuum, without a > general buy-in. > > > -- Terry > -- 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?20030221201728.A80661>