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 76B7E138010 for ; Fri, 7 Sep 2012 12:37:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4C5D721C0D2; Fri, 7 Sep 2012 12:37:17 +0000 (UTC) Received: from mail-yw0-f51.google.com (mail-yw0-f51.google.com [209.85.213.51]) by pigeon.gentoo.org (Postfix) with ESMTP id 8156721C0C6 for ; Fri, 7 Sep 2012 12:35:37 +0000 (UTC) Received: by yhnn12 with SMTP id n12so644199yhn.10 for ; Fri, 07 Sep 2012 05:35:37 -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=AVBTct08N39vzqKtiQgGlB74dGgfrrCjE6l4qrVIxkw=; b=fXbBgiS1idfTAcs5Hqb4ULxSJP52LirdgTLeGivyhmFbJ9MtIipKzkDPenZ1rvwRdN Jhqp+YQ2WFm2or417GKu27UqMqw+p9BlUtiD8FuF1I7y2HCspfQSSgxQ3zhlMqsU4dVF NBxdJYiFS7vCu1hHKZmw4W8oUOtugtHyFrga5dw3EovUSY7tWHOnb8s1c5oJFQzie2tL 4aEBnQl1lS0SIHQJQKQmixmcO+38qsM5H1LMIFfNJS6vmZVTN7C6zFTrX+ai2CCLztep dp+W+e9QseV/wli4XU8Y5rkoFEvd2JHfdC5MvI7uE9iFqZeDpYQqXcYo5reIAMJ/4DiQ 3eQQ== Received: by 10.236.139.233 with SMTP id c69mr4929971yhj.9.1347021337050; Fri, 07 Sep 2012 05:35:37 -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 v5sm4372250anj.16.2012.09.07.05.35.35 (version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 05:35:36 -0700 (PDT) Message-ID: <5049EA16.3080002@gmail.com> Date: Fri, 07 Sep 2012 07:35:34 -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: <20120906111136.GC2442@nicolas-desktop> <5048898C.7070301@gmail.com> <20120906134646.GH2442@nicolas-desktop> <5048B120.2030905@gmail.com> <5048D2D7.1070000@gmail.com> <20120906212107.6d7dcc64@hactar.digimed.co.uk> <504910F8.5010205@gmail.com> <20120906233845.65eb840f@digimed.co.uk> <50492D07.6090004@gmail.com> <20120907074722.GA2419@nicolas-desktop> In-Reply-To: <20120907074722.GA2419@nicolas-desktop> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 1f2863d9-0ead-4a82-906d-e12bc3c8c3e9 X-Archives-Hash: c6fcf102f3e2b298e34bb8ec414c6acf Nicolas Sebrecht wrote: > The 06/09/12, Dale wrote: > >> But whether it is on tmpfs or just regular memory doesn't matter. Once >> emerge starts, everything is in ram including portages work directory >> which would be on tmpfs here. That's why it doesn't matter if portage >> is on tmpfs or not. Once emerge loads up the files, it's the same >> thing. That's why using tmpfs doesn't matter. I knew that the whole >> time. The amount of ram on a system doesn't matter either. If you have >> a system that doesn't have a lot of ram, then you can't really use tmpfs >> anyway. That is not something I would recommend to anyone. > But you're wrong with this assumption. I guess you never tried to > upgrade a Gentoo system running as server (a working one, with users and > workload). Actually, I do that a lot here but we were not testing this on a server but on what a regular user would have. I ran most of my tests while in single user mode tho. I didn't want the fact that I use KDE and it may be doing something to use CPU resources or even memory to skew the results. I went over this in another reply long ago. > > The amount of memory is only /one/ helper parameter to not see a > difference. > > Like I've already said, the issue is all about the persistence strategy > used by the VM to mark memory as pinned, reclaimable or swappable. Where > tmpfs do change the matter is that a file stored in it is not going be > dropped from RAM until there is a unlink(2) call on it or that other > running processes are running out of memory and some page needs to be > swapped (so there is _already_ no more available RAM in the kernel cache). > > If not using tmpfs and because memory cache is the first place where the > kernel will free up memory, you don't have to wait for the processes to > run out of available memory to hit a situation where you'll have to wait > for the disk to retrieve files. So, this will affect times. > Swap was disabled when I ran the tests even tho I have it set to not use swap unless it is a must. Memory is memory whether it is tmpfs or just being used by a process or as disk cache. I only have one type of memory in my system here. It is all the same no matter how the system uses it. Since the only setting changed was where the work directory was located, then emerge pinned the use of memory the same in both cases. As it should. The thing is tho, whether it is using the memory as cache or using it as tmpfs, it is the same memory. There is no difference. That's the whole point. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!