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 96EF7138010 for ; Thu, 6 Sep 2012 16:55:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 94EF621C0A6; Thu, 6 Sep 2012 16:54:58 +0000 (UTC) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.213.181]) by pigeon.gentoo.org (Postfix) with ESMTP id B316A21C064 for ; Thu, 6 Sep 2012 16:49:57 +0000 (UTC) Received: by yenq6 with SMTP id q6so372954yen.40 for ; Thu, 06 Sep 2012 09:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=EaovFurcvmRYwQB88fYNnGKSGn2SpGs+hDCRoTQUHxY=; b=Ezj4j4MR0t08RPaZmXK8RSgdo1I6x9As7VB8uo6MX5AExadPlXe3MnAVmHC/lCZmG4 jWCzNRf4nDf7QbJegPbFTObZJBq/c7/13d6ZIQdPL/MEKxxjz+AtLzQRrKd8AvhBAjUO oi0TPOMKvD+n/rxammXuMUUuQBPSKPs5lJsCXvil41KXVGMOdri/2qr1PRNrLcrFhyk/ kwTjWNkePBmsVaRyBgi+kRrPxj2c4Si2Zl9pNqUcrm+P9sk3sT3rcbHiaa7i0aDUM+t5 3Ns7SYBrHB8sbBoGir76tObwUYi6Qt19f8jsTdYtFEXcLKU5612ehT+nobLtfV0OfAdr Pn9Q== Received: by 10.101.139.20 with SMTP id r20mr31347ann.55.1346950197225; Thu, 06 Sep 2012 09:49:57 -0700 (PDT) Received: from [192.168.2.5] (adsl-65-0-93-201.jan.bellsouth.net. [65.0.93.201]) by mx.google.com with ESMTPS id o5sm2210540anm.17.2012.09.06.09.49.55 (version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 09:49:56 -0700 (PDT) Message-ID: <5048D432.1020601@gmail.com> Date: Thu, 06 Sep 2012 11:49:54 -0500 From: Dale User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120902 Firefox/15.0 SeaMonkey/2.12 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 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: aligning SSD partitions 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> <20120906145126.GI2442@nicolas-desktop> In-Reply-To: <20120906145126.GI2442@nicolas-desktop> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 6244b595-f603-4ec0-a5d7-197814fd85f2 X-Archives-Hash: 4f5473e264e26d07f6ebc3efe9d9f311 Nicolas Sebrecht wrote: > 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. > That's good. >> 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. But if you are going to use tmpfs, you have to have the memory available. It doesn't matter if it is tmpfs or just used in the normal way. That is my point. >> 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. That's good. >> 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. > Who doing a normal update would cut off the cache? I wouldn't. I know how to clear it but I don't know how to disable it nor would I or most likely anyone else in normal use. The point of my test was in a normal use case of emerge with or without tmpfs and if there is any difference in the emerge times. There wasn't. Once emerge starts and loads all the stuff it needs, tmpfs doesn't matter at that point. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!