From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 845D4138010 for ; Thu, 6 Sep 2012 14:58:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3053B21C044; Thu, 6 Sep 2012 14:56:48 +0000 (UTC) Received: from mercure.logifi.fr (mercure.logifi.fr [217.108.178.220]) by pigeon.gentoo.org (Postfix) with ESMTP id 46A5921C059 for ; Thu, 6 Sep 2012 14:51:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercure.logifi.fr (Postfix) with ESMTP id 3756844394 for ; Thu, 6 Sep 2012 16:51:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at mercure.logifi.fr Received: from mercure.logifi.fr ([127.0.0.1]) by localhost (mercure.logifi.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9xpaeYul6-a; Thu, 6 Sep 2012 16:51:27 +0200 (CEST) Received: from nicolas-desktop (unknown [192.168.8.78]) by mercure.logifi.fr (Postfix) with ESMTPSA id 902D94438A; Thu, 6 Sep 2012 16:51:27 +0200 (CEST) Date: Thu, 6 Sep 2012 16:51:26 +0200 From: Nicolas Sebrecht To: gentoo-user@lists.gentoo.org Cc: Nicolas Sebrecht Subject: [gentoo-user] Re: aligning SSD partitions Message-ID: <20120906145126.GI2442@nicolas-desktop> References: <20120906104744.7f0972a7@hactar.digimed.co.uk> <504876B5.7050001@gmail.com> <20120906112003.7b1235bd@hactar.digimed.co.uk> <50487E9A.3060200@gmail.com> <20120906111136.GC2442@nicolas-desktop> <5048898C.7070301@gmail.com> <20120906131754.6d9fbcb1@digimed.co.uk> <50489BBB.5090702@gmail.com> <20120906140420.26a3e3c5@digimed.co.uk> <5048AE22.3020802@gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5048AE22.3020802@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 0829e047-9ca6-49db-8edd-eabc43b62677 X-Archives-Hash: 4507babf65fe058c070ec780413e6fb7 The 06/09/12, Dale wrote: > Then take a look at it this way. If I emerge seamonkey with portage's > work directory on disk and it takes 12 minutes, the first time. Then I > clear the caches and emerge seamonkey again while portage's work > directory is on tmpfs and it is 12 minutes. Then repeat that process a > few times more. If the outcome of all those emerges is 12 minutes, > regardless of the order, then putting portages work directory on tmpfs > makes no difference at all in that case. We fully agree with you, here. > The emerge times are exactly > the same regardless of emerge using cache or not or portage's work > directory being on tmpfs or not. I don't care if emerge uses cache > DURING the emerge process because it is always enabled in both tests. But you *should* care. If you don't have enough memory, the kernel will reclaim memory from the pagecache, so the whole process rapidity won't only rely on RAM rapidity anymore. > The point is whether portage's work directory is on tmpfs or not makes > emerges faster. > > The thing about what you are saying is that I ran those tests with the > files in memory. What I am saying is this, that is not the case. I am > clearing that memory with the drop_cache command between each test. You > claim that cache is affecting the timing but I am clearing the very same > cache the same as a reboot would. The emerge times whether portage's We do agree with you that you droped the cache between the tests with almost the same effect of a reboot. > The emerge times whether portage's > work directory is on tmpfs or not didn't change enough to make a > difference. Yes, we agree. You droped the cache which is expected to get correct tests. What we are saying is that you droped the cache but did NOT DISABLED the VM caches (kernel cache). You say that you don't care of that one because it was involved in all the tests. We say that you might not care in some contexts, not for all the contexts. You reach the context where it does not matter much, fine. -- Nicolas Sebrecht