Date: Fri, 31 May 2002 02:02:27 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: Peter Wemm <peter@wemm.org>, Richard Wenninger <richard@richardw.net>, current@FreeBSD.ORG Subject: Re: UMA lock Message-ID: <3CF73C23.A8491DC2@mindspring.com> References: <20020529061540.88CD6380A@overcee.wemm.org> <3CF475E3.8925781A@mindspring.com> <20020529091152.B61073@unixdaemons.com> <3CF53430.49B6F618@mindspring.com> <20020529162214.A62435@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bosko Milekic wrote: > Then *you* can set *your* timer to hang to infinity. *I* have > provided *the* ability to do *that*: > > tesla# sysctl -A | grep mbuf_wait > kern.ipc.mbuf_wait: 32 > tesla# sysctl -w kern.ipc.mbuf_wait=0 > > (Now the mbuf code will behave in such a way that it will hang forever > if you call with M_TRYWAIT and cannot allocate anything). > > However, *I* want to be able to do otherwise, because *I* don't agree > with *you*. So *I* will leave my timer to whatever the hell I please > and *I* will require callers to check for NULL in all cases, and > handle the failure appropriately, because that's what good systems do. > If for my particular chunk of code or subsystem, "properly" means > "call panic()," then so be it. But if for my particular subsystem it > happens to be *SOMETHING OTHER THAN CALLING panic()*, I want to be > able to catch that failure and handle it after the wait has timed out. I'm OK with trapping conditions differently. But I think an explicit timer allows for that. I really dislike having different rules for mbuf allocation vs. other allocations. I don't like that options have changed from: o Fail rather than waiting, if you would have to wait o If you have to wait, then wait until you will not fail To: o Fail rather than waiting, if you would have to wait o If you have to wait, then wait until you will not fail, but fail if you know that waiting will do no good I don't mind the new option (which is effectively "TRYWAIT"), but I dislike losing the old option. I know you worked a long time on the mbuf allocator. There was, at one time, an intention to move to a new allocator architecture for everything, based on your work, where your work was advertised as a "proof of concept" (this advertising kept many people from complaining too loudly, at the time, since it wasn't a commitment). Then the slab allocator work came in, and while it has statistics locks and some other locks I'd rather it didn't have (since the idea was to divide up the flow to prevent needing locking, and we ended up locking anyway), it seems to fill the same ecological niche that the work based on your proof of concept work would have been filling. Personally, I use my own mbuf allocator on physical memory that was reserved at boot time, so that it has incredibly lower overhead than either the allocator before your work, the allocator after it, or the slab allocator. I don't expect that it's generally useful (most of you people are not building FreeBSD-based networking hardware, so that approach would not be useful to you, anyway). But that fact that the "proof of concept" was limited to an area where I didn't have to use the code at all, also contributed to my personal lack of loud objection to the code. -- 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. -- Terry 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?3CF73C23.A8491DC2>