Date: Mon, 17 Feb 2003 20:21:07 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: mb_alloc cache balancer / garbage collector Message-ID: <Pine.BSF.4.21.0302172007580.16142-100000@InterJet.elischer.org> In-Reply-To: <20030217230327.A68207@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 17 Feb 2003, Bosko Milekic wrote: > > On Mon, Feb 17, 2003 at 07:45:45PM -0800, Julian Elischer wrote: > > On Mon, 17 Feb 2003, Bosko Milekic wrote: > > Right, it basically means that in this scenario we degenerate to a > single cache. The structure to which the mbuf is freed is called a > "bucket" and right now a "bucket" keeps a PAGE_SIZE worth of mbufs. > The idea is that you can move these buckets around from cache to > cache, even if they're not totally full. In the scenario that you > describe (which by the way is still inexistent), assuming that we > determine that it's really worth doing the binding of the threads to > individual CPUs (I'm not quite convinced that it is, ... yet), in that was a contrived example, however I can imagine many cases where the networking thread runs on one CPU, and tries to stay there due to affinity issues, which means that the fielding of interrupts and hense filling of mbufs, is left to the other CPU. I'm not saing that NICS need to be bound to processors (though if they were part of the processor unit as in some older SUN boxes that might make sense) but I am saying that I think that the producer and consumer might quite easily be constantly on different CPUs. Here's another example. One of the things that we will be doing in threads is the ability to bind a thread to a CPU. If that thread opens a socket, and starts receiving stuff then the 'consumer' is now locked to one CPU. Now let's make that thread also be using about 100% of that CPU. The other CPU is idle and therefore probably the producer is going to run there. It is true that "on average" things should even out but it is also very easy to make scenarios where this isn't true. Or, two processes doing some set of transactions with each other. (both usning lots of CPU). "On average" the producer and the consumre are going to be on different CPUs. It stilll seems odd to me that the consumer has to pass it back to the producer's CPU because "on average" it will require a locking cycle of some sort. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0302172007580.16142-100000>