From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JP6Fd-0002zh-19 for garchives@archives.gentoo.org; Wed, 13 Feb 2008 01:17:29 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A301CE0667; Wed, 13 Feb 2008 01:17:26 +0000 (UTC) Received: from vms040pub.verizon.net (vms040pub.verizon.net [206.46.252.40]) by pigeon.gentoo.org (Postfix) with ESMTP id 89393E0667 for ; Wed, 13 Feb 2008 01:17:26 +0000 (UTC) Received: from gw.thefreemanclan.net ([72.81.8.99]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JW500K7UL0LWOM0@vms040.mailsrvcs.net> for gentoo-amd64@lists.gentoo.org; Tue, 12 Feb 2008 19:19:33 -0600 (CST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw.thefreemanclan.net (Postfix) with ESMTP id 2CF5C12418F for ; Tue, 12 Feb 2008 20:17:14 -0500 (EST) Date: Tue, 12 Feb 2008 20:17:14 -0500 From: Richard Freeman Subject: Re: [gentoo-amd64] tmpfs help In-reply-to: <200802130149.14808.volker.armin.hemmann@tu-clausthal.de> To: gentoo-amd64@lists.gentoo.org Message-id: <47B2451A.5020505@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-15; format=flowed Content-transfer-encoding: 7bit References: <200802130149.14808.volker.armin.hemmann@tu-clausthal.de> User-Agent: Thunderbird 2.0.0.9 (X11/20071116) X-Archives-Salt: 8cfd63a2-5722-4511-8cf7-ca743c8ec6ea X-Archives-Hash: 795b46e7ed6d6eb39a5f8d3ab5c3a818 Volker Armin Hemmann wrote: > > with your small amount of memory tmpfs hurts you more than helps you. The > small compilations might to be sped up. But what about the big ones? > > Slow downs, because swap is used. Big slow downs, because swap is horribly > slow. Do you have benchmarks to support this? Why would swap be any slower than compiling to disk? If the compilation generates 6GB of files and you have 512MB of spare RAM, then most likely 5.5GB of that stuff will have gotten written to disk during the course of compilation - with very opportunistic writing. The last 512MB of data will probably be deleted from RAM before it ever gets written. On the other hand, without a tmpfs then all 6GB is guaranteed to be written to disk. Any files that are created and deleted 10 seconds later will be written to disk with a guaranteed sync. Every write will get synced withing a few seconds. I would think that swap would be more efficient than a million files on a filesystem. The kernel can flush tmpfs pages at any time - and it doesn't have a compulsion to flush out writes immediately since there isn't any sense of permenancy to the data. > Slow downs in daily usage because space that could be used for > cache&buffers is wasted for tmpfs. As opposed to wasting all your RAM on cache&buffers to hold all those files being accessed? During compilation that RAM is going to be heavily used - no getting around that. Once you're done any files left sitting on a tmpfs will just get paged out until accessed. They shouldn't really use any RAM at all. Even if those files were on disk they would consume RAM in the form of caching until they're considered unneeded. Basically tmpfs lets the kernel have more flexibility in memory management, while with disk-based temporary filesystems you're forcing the kernel to treat temporary data the same way you'd treat more critical files. I know that this is a bit of a religious debate, however I believe it is full of misconceptions. I'd be very interested in actual benchmarks - although I'm sure this stuff isn't easy to test. I certainly agree that swap is slow compared to RAM, but it isn't slow compared to a disk-based filesystem. Of course adding more RAM will never hurt, but that incurs significant cost and you can at least maximize your current hardware before investing in more of it. -- gentoo-amd64@lists.gentoo.org mailing list