From owner-freebsd-net Tue Oct 31 7:24:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from hurlame.pdl.cs.cmu.edu (HURLAME.PDL.CS.CMU.EDU [128.2.189.78]) by hub.freebsd.org (Postfix) with ESMTP id 7563737B680 for ; Tue, 31 Oct 2000 07:24:31 -0800 (PST) Received: (from magus@localhost) by hurlame.pdl.cs.cmu.edu (8.11.0/8.11.0) id e9VFOCX26987; Tue, 31 Oct 2000 10:24:12 -0500 (EST) (envelope-from magus) To: Andre Oppermann Cc: Alfred Perlstein , Bosko Milekic , freebsd-net@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists References: <20001030104457.E22110@fw.wintelcom.net> <39FDD039.594CED43@telehouse.ch> <39FEA159.EB774F1E@telehouse.ch> From: Nat Lanza Date: 31 Oct 2000 10:24:12 -0500 In-Reply-To: Andre Oppermann's message of "Tue, 31 Oct 2000 11:39:21 +0100" Message-ID: Lines: 37 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andre Oppermann 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