Skip site navigation (1)Skip section navigation (2)
Date:      31 Oct 2000 10:24:12 -0500
From:      Nat Lanza <magus@cs.cmu.edu>
To:        Andre Oppermann <oppermann@telehouse.ch>
Cc:        Alfred Perlstein <bright@wintelcom.net>, Bosko Milekic <bmilekic@dsuper.net>, freebsd-net@FreeBSD.ORG
Subject:   Re: MP: per-CPU mbuf allocation lists
Message-ID:  <uoclmv5vxsz.fsf@hurlame.pdl.cs.cmu.edu>
In-Reply-To: Andre Oppermann's message of "Tue, 31 Oct 2000 11:39:21 %2B0100"
References:  <Pine.BSF.4.21.0010301256580.30271-100000@jehovah.technokratis.com> <20001030104457.E22110@fw.wintelcom.net> <39FDD039.594CED43@telehouse.ch> <uoc7l6pyail.fsf@hurlame.pdl.cs.cmu.edu> <39FEA159.EB774F1E@telehouse.ch>

next in thread | previous in thread | raw e-mail | index | archive | help
Andre Oppermann <oppermann@telehouse.ch> writes:

> No. First, you contradict yourself here and second if two Apache childs
> are simultaniusly running on two CPU's they are competing at the same
> time for the resource mbuf and one will starve the other and we have a
> lot of contention.

You misunderstand. I said "if there is only one process". I wasn't
talking about the Apache case, single-threaded or multi-threaded.

Also, I don't see how multiple consumers on the same CPU will starve
each other. Really, I don't see why a number of consumers running on
a single CPU is significantly different from a single consumer on that
CPU.

Basically, I think you're pointing out problems that don't
exist. Maybe I'm wrong and these problems are real and significant,
but it's probably best to wait until this code is implemented and
working and actually test it to see if you're right about this sort of
starvation.

> You have multiple mbuf consumers, see above. Also I made a point about
> wasting mbufs when you tune the high watermark for high loads.

Well, yes. With tunable knobs like that you're always going to have
the one-setting-does-not-fit-all-circumstances situation. Again, I'm
not convinced that this is a huge problem, and I'd rather see the code
up and running and look at how it really performs before complicating
it with performance tweaks that may or may not help.


--nat

-- 
nat lanza --------------------- research programmer, parallel data lab, cmu scs
magus@cs.cmu.edu -------------------------------- http://www.cs.cmu.edu/~magus/
there are no whole truths; all truths are half-truths -- alfred north whitehead


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?uoclmv5vxsz.fsf>