Date: Fri, 21 Feb 2003 15:19:17 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: Hiten Pandya <hiten@unixdaemons.com>, FreeBSD-arch@FreeBSD.ORG Subject: Re: Mbuf flags cleanup proposal Message-ID: <3E56B3F5.9EF3F9FE@mindspring.com> References: <20030221151007.GA60348@unixdaemons.com> <3E5673E7.F3F1FA4F@mindspring.com> <20030221150743.A79345@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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?3E56B3F5.9EF3F9FE>