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


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,

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to