On Tue, 2 Jul 2002, Bosko Milekic wrote:
... <cut>
> > > Here's what happens:
> > >
> > > Consumers A and B each keep their own "pools" of mbufs+clusters.
> > > ...
> >
> > look, this is exactly what happens with network interfaces. If
> > they fail to allocate a new mbuf, they keep recycling
> > the one they have from the receive queue instead of freeing it.
>
> Yes, but that's because they _need_ an mbuf, they can't get one, so
> they re-use one. If you build a local pool in which you store UNUSED
> mbufs, with no real idea of when they'll be used - only with the
> assumption/hope that you'll use them "soon" - and if you do this in
> several different places in the kernel, you are bound to hit brokeness
> under heavy load, when you need to block from other locations to get
> your network buffers and cannot do that because someone else is
> "assuming" they'll need a bunch "sometime soon."
But if it is tunable ? And if it can be tuned for specific task that the
signle machine do ? As example you can set something like "keep_buffers"
for parts of system that you need to work faster in your single case. It
could be a kernel variable, #ifdef or both.
>
> This is why we have per-CPU caches and a global cache. The per-CPU
> caches load themselves accordingly, and they'll give you what you're
> looking for when you need it, from a cache. Sure, the caches are a
> tad bit more expensive to twiddle, but this is the compromise we make
> in order to ensure that the system knows about our caches and is able
> to cope even under heavy load.
>
> > cheers
> > luigi
>
> --
> Bosko Milekic
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
