1 |
Pascal BERTIN <pascal.bertin@×××××××.com> posted |
2 |
47B17CA6.9000506@×××××××.com, excerpted below, on Tue, 12 Feb 2008 |
3 |
12:01:58 +0100: |
4 |
|
5 |
> Beso a écrit : |
6 |
[Pascal wrote...] |
7 |
>> You can give a size for tmpfs in the option here is an extract from |
8 |
>> my /etc/fstab : |
9 |
>> |
10 |
>> tmp /tmp tmpfs size=1000000000 0 0 |
11 |
>> |
12 |
>> i'll try that. setting it to about 3/4 of swap is good?! i have 8gb |
13 |
>> swap and 1 gb ram but ram is always full. after setting tmpfs the ram |
14 |
>> is full but also the swap fills-up quite well. |
15 |
> |
16 |
> On one of my system, with 1G of RAM and 6 GB of swap, I set it to 6GB |
17 |
> (so that I can compile openoffice). Although It's slow (anyway I start |
18 |
> openoffice compilation at the end of a day and check on the next |
19 |
> morning), it works well, and openoofice compiles. |
20 |
|
21 |
Agreed. |
22 |
|
23 |
On the worth it or not thing, certainly 1 gig real memory is a bit low |
24 |
for compiling into using tmpfs, but for the reasons Richard F gave, it |
25 |
should in theory at least, remain faster than compiling into a temp |
26 |
location on disk. |
27 |
|
28 |
As he points out, if it's compiled to disk, it (1) sits in cache and is |
29 |
thus in memory anyway, and (2) if it's in cache more than a few seconds, |
30 |
it's flushed to disk thus incurring the slowdown of writing to disk. |
31 |
|
32 |
If it's compiled to tmpfs, then as the kernel needs memory, it writes out |
33 |
the least recently accessed stuff to swap. That applies regardless of |
34 |
whether it's apps or tmpfs data that's last used (as for cache, that |
35 |
depends on the swappiness setting, /proc/sys/vm/swappiness, with a |
36 |
default of 60, 0 means dump all cache before swapping apps, 100 or higher |
37 |
means swap apps before dumping cache, so 60 is leaning just slightly |
38 |
toward keeping cache and swapping apps). Thus, the active and most |
39 |
recently active parts of the compiler won't be swapped out if there's |
40 |
less recently active tmpfs files to swap first. Similarly with the |
41 |
scratch data on tmpfs. In theory, that should be the most efficient use |
42 |
of memory possible, certainly more so than using conventional disk for |
43 |
temp data, since that forces it to disk while likely keeping it in cache |
44 |
anyway. |
45 |
|
46 |
However, the theory doesn't always match reality as I'm sure most of us |
47 |
realize by now. Whether it does here or not, I haven't tested, and as |
48 |
I've 8 gigs memory, don't care to test for the 1 gig situation. |
49 |
|
50 |
Regardless, I think we can all agree that it'll be far more practical |
51 |
with 2-4 gigs of memory, and for most, the upgrade from 1 to 2 gigs |
52 |
minimum for memory should be well worth it in terms of value for cost. |
53 |
|
54 |
Meanwhile, I say let the folks dealing with the problem decide their |
55 |
policy, testing it and reporting the results if they feel the desire too, |
56 |
or just going with what they think works best for them if not. |
57 |
|
58 |
Given that some are choosing to try it, regardless of why, the original |
59 |
question deserves an answer, as Pascal posted above. It may however be |
60 |
worth noting that mount also accepts more human readable numbers as well, |
61 |
6G or whatever instead of the long string of numbers. Thus, here's my |
62 |
entry: |
63 |
|
64 |
/tmp /tmp tmpfs size=6g,nodev,nosuid 0 0 |
65 |
|
66 |
Again, that's with 8 gigs RAM, so I don't have to worry about swapping so |
67 |
much, tho even when I do it's to 4-way striped swap, so 4 times as fast |
68 |
as a single disk would be, and I have swappiness set to 100, so the |
69 |
kernel swaps apps (at 4-way-stripped swap, twice as fast as reading them |
70 |
in off 4-way RAID-6, thus two-way-striped), keeping cache intact. That |
71 |
works great for me! =8^) Whether it works better than a disk based /tmp |
72 |
and PORTAGE_TMPDIR for those with only a gig of memory is something they |
73 |
ultimately must decide, regardless of the arguments pro and con here. |
74 |
|
75 |
FWIW and for clarity, since there seems to be a bit of confusion between |
76 |
tmpfs as used here and the FHS/LSB mandated /dev/shm, I have an entry for |
77 |
that as well: |
78 |
|
79 |
shm /dev/shm tmpfs size=20m,noexec,nodev,nosuid 0 0 |
80 |
|
81 |
Note that it's a separate entry. More than one tmpfs mount is allowed |
82 |
and they are all kept separate. Also note that I have the max size set |
83 |
far smaller for it than for /tmp, since I don't have much that uses it |
84 |
and only keep it around in case something wants to. (I do have |
85 |
PORTAGE_TMPFS, which is used for very small files, lock files and the |
86 |
like, set to /dev/shm, so portage uses it for that even tho |
87 |
PORTAGE_TMPDIR is set to /tmp, for the much bigger stuff.) |
88 |
|
89 |
I actually have another tmpfs mount as well, /dev, for udev: |
90 |
|
91 |
dev /dev tmpfs mode=0755,size=2m,noexec,noauto 0 0 |
92 |
|
93 |
baselayout-1 users won't have that entry in fstab, as it sets it |
94 |
differently, but may have the following instead (tho I think this was |
95 |
left over from the never stabilized AFAIK baselayout-1.13-alphas): |
96 |
|
97 |
init.d /lib64/rcscripts/init.d tmpfs mode=0755,size=512k,noauto 0 0 |
98 |
|
99 |
So I actually have four tmpfs entries in fstab, altho only three are |
100 |
active as that last one is left from an earlier time because the scripts |
101 |
no longer call for it to be mounted and the general system mount ignores |
102 |
it due to the noauto. All four are entirely separate mounts, separate |
103 |
options, seperate mountpoints, and separately treated by the system. |
104 |
|
105 |
Also, a warning I've started noting every time this comes up, those who |
106 |
point PORTAGE_TMPDIR at a tmpfs AND use ccache will want to make sure |
107 |
CCACHE_DIR is pointed somewhere other than a subdir of PORTAGE_TMPDIR, |
108 |
since keeping ccache files around is rather the point of running it, but |
109 |
the default as found in make.conf.example is to point it at a subdir of |
110 |
PORTAGE_TMPDIR. |
111 |
|
112 |
-- |
113 |
Duncan - List replies preferred. No HTML msgs. |
114 |
"Every nonfree program has a lord, a master -- |
115 |
and if you use the program, he is your master." Richard Stallman |
116 |
|
117 |
-- |
118 |
gentoo-amd64@l.g.o mailing list |