Tmpfs in 64bit

lilsirecho · 2009-09-03 21:29:37

With core2 duo x86-64 the ram required is "paired" for the cores.

This means that half of the ram applies to core0 and the other half to core1.

Tmpfs defines itself as half of physical ram AFAIK.

This means that, AFAICT, with 4GB of ram(2x2GB sticks) each core sees 1GB of tmpfs available to it.

Is this conclusion correct?

Many posts report slowdowns in file transfers in 64bit. Can increasing the available tmpfs for each core to max value(2GB) have a positive effect on transfer speed?

This could be done with:

mount -o remount,size=2G /

Or mebbe I have lost something in my 84th year!
EDIT: Mebbe the system will respond to:

mount -o remount,size=4G /

or not................

EDIT 2: I note in my 64 bit system /dev/shm and not tmpfs which means the codes won't respond. Tmpfs has to be created first.

Last edited by lilsirecho (2009-09-03 23:25:02)

lilsirecho · 2009-09-03 23:55:24

Perhaps it is only necessary to change /dev/shm per the following:

mount -o remount,size=4G /dev/shm  ( for example)

This code changes the size of /dev/shm to 4G in df -h.

klixon · 2009-09-04 04:51:32

the size parameter for tmpfs lets you override the maximum size it will grow to, which is half of your total mem size.
tmpfs always starts at zero and expands with files you put on it.

lilsirecho · 2009-09-04 17:29:53

The remount of /dev/shm permits the use of tmpfs up to the maximum allowed memory for the core in use AFAICT. This does not mean per se that 4GB is available for a given core but does permit more than half of physical memory for a given core.

The exact performance of x86-64 cores with respect to memory assigned is beyond my purview, I only express an interest in the effects of permitting full use of available memory. The exact amount is in question for dual core systems since they seem to divide memory into two sticks in dual core AFAICT.

Any info on the subject of assigned memory in dual core would be appreciated.

Memory needs in 64bit are doubled in dual core systems. To get 4GB of memory for each core you need 8GB of physical memory.

The possible impact of increasing the tmpfs size (/dev/shm) to mitigate the slowdowns in file transfers is of interest.

Teoulas · 2009-09-06 10:51:59

lilsirecho wrote:

With core2 duo x86-64 the ram required is "paired" for the cores.
This means that half of the ram applies to core0 and the other half to core1.

Are you sure? As far as I know, each core has it's own level 1 and level 2 cache, but both have access to all RAM.

lilsirecho · 2009-09-06 16:02:58

Googling on the cache item reveals that core 2 duo uses a common L2 cache .

Most comments about core 2 duo 64 bit state that double the memory is required and matched sticks to satisfy two-core memory requirements. Therefore each core gets half of physical memory and tmpfs/shm utilizes half of that value. This is my understanding of core 2 duo.

L2 cache is reported as being a shared cache, in my machine 2MB.

Remount of shm/tmpfs allows maximum use of available memory which may not be all of physical memory but just one-half of the physical memory as is made available to core 2 duo cores. Perhaps this is incorrect?

If it weren't for the strict requirement to have matched sticks I would not reach this conclusion.

I am open for critique on the subject and instruction if needed.

(One could consider the ram manufacturers glee when considering sticks filling the requirements for six cores!)

R00KIE · 2009-09-06 18:44:10

I believe you are thinking about dual channel operation, indeed to get the most bandwidth possible you need to have similar memory sticks but both cpus can access all the ram.

Also I think that increasing the maximum size of tmpfs may be a big mistake, like klixon said only the space needed to store the files _inside_ the mount will actually be used in the ram. I don't know if when copying files from one place to the other the storage at /dev/shm is used or not, I believe not, I've read somewhere that the tmpfs mounted in /dev/shm is allocated for some sort of interprocess communication only (I may be wrong here).

Also by allowing the tmpfs to grow to the size of your ram you are asking for trouble, if some rogue app decides to fill the whole of /dev/shm your pc will crawl to a halt or crash.

As far I could understand, the problem with slowdowns while copying big files from one place to the other has no easy fix and is due to the way things work in the kernel.

Search a bit here in the forum and I'm sure you will find some posts about that with links pointing to other pages where part of the problem is explained.

lilsirecho · 2009-09-06 19:06:49

Have noted the discussions about cache problems which is one reason for my suggestion about increasing the size of temp/shm.

There seems to be no solution to the transfer of large files at present.

Mine was only a suggestion.

Whereas as you post both cores have access to full ram, but L2 cache is shared, so therein is a bottleneck if full access is available for the two cores in core duo.

It may get even more complex with six cores!!

Thanks for your advice............

Arch Linux

#1 2009-09-03 21:29:37

Tmpfs in 64bit

#2 2009-09-03 23:55:24

Re: Tmpfs in 64bit

#3 2009-09-04 04:51:32

Re: Tmpfs in 64bit

#4 2009-09-04 17:29:53

Re: Tmpfs in 64bit

#5 2009-09-06 10:51:59

Re: Tmpfs in 64bit

#6 2009-09-06 16:02:58

Re: Tmpfs in 64bit

#7 2009-09-06 18:44:10

Re: Tmpfs in 64bit

#8 2009-09-06 19:06:49

Re: Tmpfs in 64bit

Board footer