Date: Thu, 04 Mar 2004 12:53:33 +0800 From: Erich Dollansky <oceanare@pacific.net.sg> To: Simon <simon@optinet.com> Cc: "hardware@freebsd.org" <hardware@freebsd.org> Subject: Re: Xeon w/ L3 1MB cache vs Xeon w/o L3 cache Message-ID: <4046B64D.8070503@pacific.net.sg> In-Reply-To: <20040304043552.YWFG14426.maxis2.pacific.net.sg@cobra.acceleratedweb.net> References: <20040304043552.YWFG14426.maxis2.pacific.net.sg@cobra.acceleratedweb.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Simon wrote: > Thanks, I read that under higher loads, the L3 cache becomes quite useful, too. > But, what is considered high-load? what determines if L3 cache is used or not? The range is very wide. I would define it for your case as soon as cache trashing starts. > is it app to the app to use it? or up to the kernel? or the CPU itself? or a The CPU decides normally what is stored in the different caches. Kernels and applications can help to support the CPU's decision. But I do not know of any application supporting this. > combination? We run a lot of services on our servers and I would say they are > heavy loaded, but I could be mistaking, I mean, they do a lot of processing but > not exactly crawling, they are still fast. > This sounds the envirnoment where I did those tests. Without knowing what was in the boxes we started wondering some machines started crawling for a short period of time while others did not. A machine with some MB of extra L3 cache starts crawling much later. The impact to the machine cannot predicted precisely. It depends very much on the application. My experience ranges form hardly any impact up to 30 times higher throughput. It sounds like you have a lot of machines. I would consider getting one machine with larger L3 caches to test it. You also should consider this: http://www.anandtech.com/IT/showdoc.html?i=1982 The cache does not really help if the memory interface becomes the bottle-neck. Erich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4046B64D.8070503>