FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 09-06-2012, 10:56 AM
Dale
 
Default aligning SSD partitions

Neil Bothwick wrote:
> On Thu, 06 Sep 2012 05:03:55 -0500, Dale wrote:
>
>>>> You miss this point not me. I *cleared* that cache. From
>>>> kernel.org:
>>> Sorry Dale, but you are missing the point. You cleared the cache
>>> before running emerge, then ran emerge. The first thing emerge did
>>> was unpack the tarball and populate the disk cache. All clearing the
>>> disk cache did was make sure there was plenty of space to cache the
>>> new data, thus speeding up the process.
>> Then explain to me why it was at times slower while on tmpfs? Trust me,
>> I ran this test many times and in different orders and it did NOT make
>> much if any difference.
> So it was slower at times, but not by much? That's just general variances
> caused by multi-tasking, wind direction etc.

That's the point. It doesn't make any difference whether you have
portages work directory on tmpfs or not. For the point of this thread,
it would be a good idea to save wear and tear on the SSD but one should
NOT expect that emerge will compile packages any faster because of it
being on tmpfs instead of on disk. I might also add, I ran some of my
tests in single user mode. That is about as raw as Linux gets but there
is still the chance of variances here and there. That's why I said not
much. Sometimes one would be a second or two faster then next time be a
second or two slower. Basically, just normal variances that may not be
related to one another.

>
>> I might add, the cache on the drive I was using is nowhere near large
>> enough to cache the tarball for the package. Heck, the cache on my
>> current system drive is only 8Mbs according to hdparm.
> We're not talking about drive caches, the kernel caches filesystem access
> long before it gets anywhere the drive. So all the real work is done in
> RAM if you have enough, whether you are using a hard drive filesystem or
> tmpfs. All your test demonstrates is that if you have enough RAM, it
> doesn't make much difference where you put PORTAGE_TMPDIR.
>
>

The command mentioned several replies back CLEARS that cache. When you
run that command to clear the cache, from my understanding, at that
point it is as if the command has never been run since the last reboot.
Meaning, the command, emerge in this case, and its children are NOT
cached in ram nor is anything else. I posted that from kernel.org.
That's their claim not mine. If you don't accept that clearing the
cache works, you need to talk to the kernel people because they are
saying it there and I'm just repeating it here. A link for you to read:

http://www.kernel.org/doc/Documentation/sysctl/vm.txt

Just scroll down to the section about drop_caches. Read it for yourself
if you can't/won't accept me saying it.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
 
Old 09-06-2012, 11:03 AM
Dale
 
Default aligning SSD partitions

Nicolas Sebrecht wrote:
> The 06/09/12, Dale wrote:
>
>> Then explain to me why it was at times slower while on tmpfs? Trust me,
>> I ran this test many times and in different orders and it did NOT make
>> much if any difference.
> As explained, this is expected if you have enough RAM.
>
> I didn't check but I would expect that files stored in tmpfs are NOT
> duplicated in the the kernel cache in order to save RAM. So, the
> different times could come from the fact that the kernel will first look
> up in the kernel cache and /then/ look up in the tmpfs.
>
> In the scenario without tmpfs and lot of RAM, every unpacked file is
> stored in the _kernel cache_ with really fast access much before hitting
> the disk or even the disk cache (RAM speed and very few processor
> calculation required). While retrieving, the file is found on first look
> up from the kernel cache.


The point you are missing is this. Between those tests, I CLEARED that
cache. The thing you and Neil claim that makes a difference does not
exist after you clear the cache. I CLEARED that cache between EACH and
every test that was ran whether using tmpfs or not. I did this instead
of rebooting my system after each test.


>
> In the other scenario with tmpfs and lot of RAM, every unpacked file is
> stored in the tmpfs allowing very fast access (due to RAM speed) but
> with the price of a first negative result from the kernel cache (and
> perhaps additional time needed by the kernel for accessing the file
> through the driver of the tmpfs filesystem).
>
> Using tmpfs will still be better as it prevents from writes to the disk
> in the spare times, avoiding unnecessary mecanic movements and saving
> disk life time.

The thing is, this was tested because people wanted to see what the
improvements was. When tested, it turned out that there was very little
if any difference. So, in theory I would say that using tmpfs would
result in faster compile times. After testing, theory left the building
and reality showed that it did not make much if any difference.

>> I might add, the cache on the drive I was using is nowhere near large
>> enough to cache the tarball for the package. Heck, the cache on my
>> current system drive is only 8Mbs according to hdparm. That is not much
>> since I tested using much larger packages. You can't cache files larger
>> than the cache.
> The disk cache is out of the scope.

True, just wanted to make sure we were talking about the same cache here.

>
>> Do I need to run a test, reboot, run the test again to show this is not
>> making much if any difference? I mean, really? o_O
> It won't make any difference from the drop cache configuration but it is
> still not the point!
>

Well, why say that caching makes a difference then say it doesn't matter
when those caches are cleared? Either caches matter or it doesn't.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
 
Old 09-06-2012, 11:11 AM
Nicolas Sebrecht
 
Default aligning SSD partitions

The 06/09/12, Dale wrote:

> The point was
> whether having portages work directory on tmpfs resulted in speed
> increases. If you have portages work directory on tmpfs, of course it
> uses ram. That's what tmpfs is. It's taking what might normally be put
> on the disk and putting it in ram because ram is faster.

Please, understand that whithout tmpfs and a lot of RAM, the kernel
_won't_ work with the files from the disk but with the files stored in
the _kernel cache_ which IS RAM, too.

This explains why you get this result:

> The point is,
> cache or not, having portages work directory on tmpfs doesn't result in
> speed improvements as one would expect.

Taking back your last sentence with precise sementic:

The point is,
/tmpfs cache (RAM)/ or /kernel cache (RAM)/, having portages work on tmpfs doesn't result in
speed improvements.


--
Nicolas Sebrecht
 
Old 09-06-2012, 11:31 AM
Dale
 
Default aligning SSD partitions

Nicolas Sebrecht wrote:
> The 06/09/12, Dale wrote:
>
>> The point was
>> whether having portages work directory on tmpfs resulted in speed
>> increases. If you have portages work directory on tmpfs, of course it
>> uses ram. That's what tmpfs is. It's taking what might normally be put
>> on the disk and putting it in ram because ram is faster.
> Please, understand that whithout tmpfs and a lot of RAM, the kernel
> _won't_ work with the files from the disk but with the files stored in
> the _kernel cache_ which IS RAM, too.
>
> This explains why you get this result:
>
>> The point is,
>> cache or not, having portages work directory on tmpfs doesn't result in
>> speed improvements as one would expect.
> Taking back your last sentence with precise sementic:
>
> The point is,
> /tmpfs cache (RAM)/ or /kernel cache (RAM)/, having portages work on tmpfs doesn't result in
> speed improvements.
>
>

Not quite. The theory is that if you put portages work directory on
tmpfs, then all the writes and such are done in ram which is faster. If
you have portages work directory on disk, it will be slower because the
disk is slower. That is the theory and was what I and others expected
to happen.

This is reality. Even when portages work directory is on tmpfs, it is
not much, if any, faster when compared to portages work directory being
on tmpfs. The two are essentially the same as far as emerge times go.

Look, I have portages work directory on tmpfs. The only time my hard
drive light comes on to amount to anything is when loading the tarball
or installing the package after the compile is done. If I take portage
off tmpfs, just unmount the directory so that it is back on disk like
most normal folks, then the hard drive light blinks all during the
compile. It doesn't make sense however, I can either accept what I
think or what actually happens. In this case, I just have to accept
that putting portages work directory on tmpfs just doesn't really do
much good except save wear and tear on the disk drive. Which, that is
why I know keep mine on tmpfs. It's also a good idea when using SSDs as
in this thread.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
 
Old 09-06-2012, 11:37 AM
Nicolas Sebrecht
 
Default aligning SSD partitions

The 06/09/12, Dale wrote:

> The point you are missing is this. Between those tests, I CLEARED that
> cache. The thing you and Neil claim that makes a difference does not
> exist after you clear the cache. I CLEARED that cache between EACH and
> every test that was ran whether using tmpfs or not. I did this instead
> of rebooting my system after each test.

We clearly understand that you cleared the cache between the tests. We
pretend that it is not much relevant for your tests because of another
process.

> So, in theory I would say that using tmpfs would
> result in faster compile times. After testing, theory left the building
> and reality showed that it did not make much if any difference.

Yes, because you did the tests on a system with lot of RAM.

If the kernel needs to retrieve a file, there is basically the following
workflow:

1. retrieve file from kernel cache;
2. if not found, retrieve file from tmpfs cache;
3. if not found, retrieve file from swap cache;
4. if not found, retrieve file from disk cache;
5. if not found, retrieve file from disk.

This is simplified workflow but you get the idea.

Now, what we are saying is that *when you have lot of RAM*, the kernel
never hit 2, 3, 4 and 5. The problem with the kernel cache is that files
stored in this cache are dropped from it very fast. tmpfs allows to have
better files persistence in RAM. But if you have lot of RAM, the files
stored in the kernel cache are /not/ dropped from it which allows the
kernel to work with files in RAM only.

Clearing the kernel cache between the tests does not change much since
files are stored in RAM again, at the unpack process time. What makes
compilation very slow from the disk are all the _next reads and writes_
required by the compilation.

> Well, why say that caching makes a difference then say it doesn't matter
> when those caches are cleared? Either caches matter or it doesn't.

It does make a difference if you don't have enough RAM for the kernel
cache to store all the files involved in the whole emerge process and
every other process run by the kernel during the emerge.

--
Nicolas Sebrecht
 
Old 09-06-2012, 12:17 PM
Neil Bothwick
 
Default aligning SSD partitions

On Thu, 06 Sep 2012 06:31:24 -0500, Dale wrote:

> Not quite. The theory is that if you put portages work directory on
> tmpfs, then all the writes and such are done in ram which is faster. If
> you have portages work directory on disk, it will be slower because the
> disk is slower.

But the disk is not used when you have enough RAM to keep everything
cached. So you are comparing the speed of storing all files in RAM with
the speed of storing all files in RAM, so it is hardly surprising that
the two tests give similar results.

The fact that in one scenario the files do end up on disk is irrelevant,
you are working from RAM copies of the files in both instances.

By running the test on a lightly loaded machine, you are also removing
the possibility of files being flushed from the cache in the
tmpdir-on-disk setup, so I would expect you to get comparable results
either way.

The only real benefit of using tmpfs is the one you mentioned elsewhere,
that the disks don't get bothered at all.


--
Neil Bothwick

Is there another word for synonym?
 
Old 09-06-2012, 12:21 PM
Dale
 
Default aligning SSD partitions

Nicolas Sebrecht wrote:
> The 06/09/12, Dale wrote:
>
>> The point you are missing is this. Between those tests, I CLEARED that
>> cache. The thing you and Neil claim that makes a difference does not
>> exist after you clear the cache. I CLEARED that cache between EACH and
>> every test that was ran whether using tmpfs or not. I did this instead
>> of rebooting my system after each test.
> We clearly understand that you cleared the cache between the tests. We
> pretend that it is not much relevant for your tests because of another
> process.
>
>> So, in theory I would say that using tmpfs would
>> result in faster compile times. After testing, theory left the building
>> and reality showed that it did not make much if any difference.
> Yes, because you did the tests on a system with lot of RAM.
>
> If the kernel needs to retrieve a file, there is basically the following
> workflow:
>
> 1. retrieve file from kernel cache;
> 2. if not found, retrieve file from tmpfs cache;
> 3. if not found, retrieve file from swap cache;
> 4. if not found, retrieve file from disk cache;
> 5. if not found, retrieve file from disk.
>
> This is simplified workflow but you get the idea.

I do get it. I CLEARED #1 and #2, there is no usage of #3 and #4 is not
large enough here to matter. So, it is left with #5.

See the point? The test was a NORMAL emerge with portages work
directory on tmpfs and a NORMAL emerge with portages work directory on
disk and compare the results. The test resulted in little if any
difference.

If I ran the test and did not clear the cache, then I would expect
skewed results because after the first emerge, some files would be
cached in ram and the drive would not be used. If you clear the cache,
then it has to take the same steps regardless of whether it was run
first, second or third time.

>
> Now, what we are saying is that *when you have lot of RAM*, the kernel
> never hit 2, 3, 4 and 5. The problem with the kernel cache is that files
> stored in this cache are dropped from it very fast. tmpfs allows to have
> better files persistence in RAM. But if you have lot of RAM, the files
> stored in the kernel cache are /not/ dropped from it which allows the
> kernel to work with files in RAM only.
>
> Clearing the kernel cache between the tests does not change much since
> files are stored in RAM again, at the unpack process time. What makes
> compilation very slow from the disk are all the _next reads and writes_
> required by the compilation.
>
>> Well, why say that caching makes a difference then say it doesn't matter
>> when those caches are cleared? Either caches matter or it doesn't.
> It does make a difference if you don't have enough RAM for the kernel
> cache to store all the files involved in the whole emerge process and
> every other process run by the kernel during the emerge.
>

But if you CLEAR the kernel cache between each test, then it doesn't
matter either. I am clearing the KERNEL cache which includes pagecache,
dentries and inodes. I can see the difference in gkrellm, top and in
what the command free gives me.

Put another way. I run a emerge on tmpfs and note the emerge times. I
reboot. I run the same emerge again with it not on tmpfs. Do we agree
that that would result in a actual real result? If yes then using the
command to clear the cache is the same as rebooting. It's the whole
point of having the feature in the kernel. The file drop_caches when
set to 3 with the echo command erases, deletes or whatever you want to
call it, the caches. That's from the kernel folks as linked to in
another reply. That's not me saying it, it is the kernel folks saying it.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
 
Old 09-06-2012, 12:44 PM
Nicolas Sebrecht
 
Default aligning SSD partitions

The 06/09/12, Neil Bothwick wrote:

> The only real benefit of using tmpfs is the one you mentioned elsewhere,
> that the disks don't get bothered at all.

Benefits also depends of what the system does during the emerge. If
another process is intensively using the kernel cache and the kernel
cache can't keep all the cached files for all the processes because it
is missing of RAM, then underlying disk rapidity (tmpfs vs bare metal
HDD) will sightly change the results.

--
Nicolas Sebrecht
 
Old 09-06-2012, 12:48 PM
Dale
 
Default aligning SSD partitions

Neil Bothwick wrote:
> On Thu, 06 Sep 2012 06:31:24 -0500, Dale wrote:
>
>> Not quite. The theory is that if you put portages work directory on
>> tmpfs, then all the writes and such are done in ram which is faster. If
>> you have portages work directory on disk, it will be slower because the
>> disk is slower.
> But the disk is not used when you have enough RAM to keep everything
> cached. So you are comparing the speed of storing all files in RAM with
> the speed of storing all files in RAM, so it is hardly surprising that
> the two tests give similar results.
>
> The fact that in one scenario the files do end up on disk is irrelevant,
> you are working from RAM copies of the files in both instances.
>
> By running the test on a lightly loaded machine, you are also removing
> the possibility of files being flushed from the cache in the
> tmpdir-on-disk setup, so I would expect you to get comparable results
> either way.
>
> The only real benefit of using tmpfs is the one you mentioned elsewhere,
> that the disks don't get bothered at all.
>
>

I don't think that is correct. I am clearing the files in ram. That's
the point of drop_caches is to clear the kernels cache files. See post
to Nicolas Sebrecht a bit ago.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
 
Old 09-06-2012, 01:04 PM
Neil Bothwick
 
Default aligning SSD partitions

On Thu, 06 Sep 2012 07:48:59 -0500, Dale wrote:

> I don't think that is correct. I am clearing the files in ram. That's
> the point of drop_caches is to clear the kernels cache files. See post
> to Nicolas Sebrecht a bit ago.

Take a step back Dale and read the posts again. This is not about the
state of the cache at the start of the emerge but during it. You may
clear the cache before starting, but that doesn't stop is filling up
again as soon as the emerge reaches src_unpack().

This has nothing to do with caching the data from the previous emerge
run, it is all from the currently running emerge. You may think you are
unpacking the tarball to disk and then loading those files into the
compiler, but you are only using the copies that are cached when you
unpack.


--
Neil Bothwick

This universe is sold by mass, not by volume.
Some expansion may have occurred during shipment
 

Thread Tools




All times are GMT. The time now is 08:06 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org