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 D0084138010 for ; Mon, 10 Sep 2012 13:55:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F07CEE0684; Mon, 10 Sep 2012 13:54:42 +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 2347AE0630 for ; Mon, 10 Sep 2012 13:53:01 +0000 (UTC) Received: by yenq6 with SMTP id q6so472471yen.40 for ; Mon, 10 Sep 2012 06:53:01 -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; bh=ogJj1whrY08+ybGULy3RAV7/31gI92OEIXOIveQh0S0=; b=0MoIFMXjM/92gUFTazkP9dD5VZOtVHK7W+PUkuKbvNRJWlzq1AfopcSeSVXDZEZw7p Bi9WH1eQHP+1rlNspxkzpIPR46/VMrkkTOoklewxYMXZm6rOLs/kRVIzWc4Y7gZJ2f3b t26Pm2oBvoGmBkMp4ofo1e4wQcRzxjnNPwoh+JQbbbBq5q4o1QYs3DHkDTfL+evLONpM lc+WNfP3V5aPwNZmYpmp2RgeQP5cslVmnKAF/31YUVGajIRvvsFUsV4OBDviETOLALeR U/p/Je+OyBQqjbw4/yMbrpTdo+wvVLb/Cc8kdYb3Aka7hOWeU9hyywQRy7cZNWAQu+UR a4hw== Received: by 10.236.155.10 with SMTP id i10mr12204329yhk.91.1347285181491; Mon, 10 Sep 2012 06:53:01 -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 e16sm11554767ani.22.2012.09.10.06.52.58 (version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 06:52:59 -0700 (PDT) Message-ID: <504DF0B7.3070000@gmail.com> Date: Mon, 10 Sep 2012 08:52:55 -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: <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> <5049EA16.3080002@gmail.com> <20120910103221.GA5984@nicolas-desktop> <504DCB74.8020408@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: multipart/alternative; boundary="------------010201020202030206090508" X-Archives-Salt: 3d46660d-cebf-4ee8-9bd8-0185f3e473c9 X-Archives-Hash: 24d4777f2cc89b6a793461f2f716542c This is a multi-part message in MIME format. --------------010201020202030206090508 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Michael Mol wrote: > On Mon, Sep 10, 2012 at 7:13 AM, Dale > wrote: > > Nicolas Sebrecht wrote: > > The 07/09/12, Dale wrote: > > > >> 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. > > Feel free to take your own assumptions as undeniable truth. The > way the > > kernel work with memory is the key, of course. > > > > Now, as long as you blind yourself with statements like that, > I'm not > > going to respond anymore. I guess you need to make some basic > research. > > > > I understand how the kernel uses memory. That's why it doesn't matter > if you put portage's work directory on tmpfs or not. I been using > Linux > for a pretty good long while now. I have a pretty good > understanding of > it, especially the things that I use. > > Respond or not, I know what I tested and what the results were. They > were not just my tests and results either. > > > Nobody is disagreeing with your test results. In fact, they're not > even disagreeing with you that they mean what you think they mean > within the context you're testing. They're disagreeing with your > extrapolation of your results to other contexts. In short, all other > things being equal, your test results work out for someone in the > exact same circumstances as yourself...but there are a _lot_ of other > things that need to be equal! > > Filesystem mount options can have an impact. For example, let's say > your filesystem is configured to make writes synchronous, for general > data integrity purposes. That would slow PORTAGE_TMP down something > _fierce_. > > Someone might be tweaking any number of the knobs under 'vm' in /proc. > vm.swappiness, vm.dirty_* or vm.min_free_kbytes are ones that caught > my eye, but really most of them in there look relevant. > > Or consider that someone else might be running drop_caches, or even > sync() while your code is running. (Heck, if there's a database, even > an sqlite database, on the same filesystem, that's almost a guarantee.) > > These may seem to be obvious, but these are the kinds of things people > were trying to get you to be willing to acknowledge before you made > blanket assertions which covered them. > > -- > :wq Someone could be getting rays from Mars but I am not testing that. What I tested was this, Run emerge with portages work directory on disk. Then run same command with portage's work directory on tmpfs. Then compare the results. No other changes except for where portage's work directory is located, hard drive or ram. This was done on a NORMAL system that most ANY user would be using. I'm not concerned with some rare or exotic setup, just a normal setup. If someone is running some exotic setup, then they need to test that to see whether it helps or not because I did not test for that sort of system. I didn't test for rays from Mars either. LOL Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! --------------010201020202030206090508 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Michael Mol wrote:
On Mon, Sep 10, 2012 at 7:13 AM, Dale <rdalek1967@gmail.com> wrote:
Nicolas Sebrecht wrote:
> The 07/09/12, Dale wrote:
>
>> 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.
> Feel free to take your own assumptions as undeniable truth. The way the
> kernel work with memory is the key, of course.
>
> Now, as long as you blind yourself with statements like that, I'm not
> going to respond anymore. I guess you need to make some basic research.
>

I understand how the kernel uses memory.  That's why it doesn't matter
if you put portage's work directory on tmpfs or not.  I been using Linux
for a pretty good long while now.  I have a pretty good understanding of
it, especially the things that I use.

Respond or not, I know what I tested and what the results were.  They
were not just my tests and results either.

Nobody is disagreeing with your test results. In fact, they're not even disagreeing with you that they mean what you think they mean within the context you're testing. They're disagreeing with your extrapolation of your results to other contexts. In short, all other things being equal, your test results work out for someone in the exact same circumstances as yourself...but there are a _lot_ of other things that need to be equal!

Filesystem mount options can have an impact. For example, let's say your filesystem is configured to make writes synchronous, for general data integrity purposes. That would slow PORTAGE_TMP down something _fierce_.

Someone might be tweaking any number of the knobs under 'vm' in /proc. vm.swappiness, vm.dirty_* or vm.min_free_kbytes are ones that caught my eye, but really most of them in there look relevant.

Or consider that someone else might be running drop_caches, or even sync() while your code is running. (Heck, if there's a database, even an sqlite database, on the same filesystem, that's almost a guarantee.)

These may seem to be obvious, but these are the kinds of things people were trying to get you to be willing to acknowledge before you made blanket assertions which covered them.

--
:wq


Someone could be getting rays from Mars but I am not testing that.  What I tested was this,  Run emerge with portages work directory on disk.  Then run same command with portage's work directory on tmpfs.  Then compare the results.  No other changes except for where portage's work directory is located, hard drive or ram.  This was done on a NORMAL system that most ANY user would be using.  I'm not concerned with some rare or exotic setup, just a normal setup.  If someone is running some exotic setup, then they need to test that to see whether it helps or not because I did not test for that sort of system.  I didn't test for rays from Mars either.  LOL

Dale

:-)  :-)  
-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
--------------010201020202030206090508--