1 |
Am Wed, 24 May 2017 07:34:34 +0200 |
2 |
schrieb gentoo-user@××××.de: |
3 |
|
4 |
> On 17-05-23 at 22:16, Ian Zimmerman wrote: |
5 |
> > So what are gentoo users' opinions on this matter of faith? |
6 |
> I use an ext4 partition backed by zram. Gives me ~3x compression on |
7 |
> the things I normally have lying around there (plain text files) and |
8 |
> ensures that anything I throw there (or programs throw there) gets |
9 |
> cleaned up on reboot. |
10 |
> |
11 |
> > I have long been in the camp that thinks tmpfs for /tmp has no |
12 |
> > advantages (and may have disadvantages) over a normal filesystem |
13 |
> > like ext3, because the files there are normally so small that they |
14 |
> > will stay in the page cache 100% of the time. |
15 |
> I've never actually benchmarked this. Most of the things I notice that |
16 |
> tend to end up there are temporary build files generated during |
17 |
> configure stages or temporary log files used by various programs |
18 |
> (clang static analyzer). Even if the entire file stays in the page |
19 |
> cache, it'll still generate IO overhead and extra seeks that might |
20 |
> slow down the rest of your system (unless your /tmp is on a different |
21 |
> hard drive) which on spinning rust will cause slowdowns while on an |
22 |
> ssd it'll eat away at your writes (which you may or may not have to |
23 |
> worry about). |
24 |
> |
25 |
> > But I see that tmpfs is the default with systemd. Surely they have |
26 |
> > a good reason for this? :) |
27 |
> Or someone decided they liked the idea and made it the default and |
28 |
> nobody ever complained (or if they did were told to just change it on |
29 |
> their system). |
30 |
> |
31 |
> Either way, it'd be nice if someone actually benchmarked this. |
32 |
|
33 |
While I have no benchmarks and use the systemd default of tmpfs |
34 |
for /tmp, I also put /var/tmp/portage on tmpfs, automounted through |
35 |
systemd so it is cleaned up when no longer used (by unmounting). |
36 |
|
37 |
What can I say? It works so much faster: Building packages is a lot |
38 |
faster most of the time, even if you'd expect gcc uses a lot of memory. |
39 |
|
40 |
Well, why might that be? First, tmpfs is backed by swap space, that |
41 |
means, you need a swap partition of course. Swap is a lot simpler than |
42 |
file systems, so swapping out unused temporary files is fast and is a |
43 |
good thing. Also, unused memory sitting around may be swapped out |
44 |
early. Why would you want inactive memory resident? So this is also a |
45 |
good thing. Portage can use memory much more efficient by this. |
46 |
|
47 |
Applying this reasoning over to /tmp should no explain why it works so |
48 |
well and why you may want it. |
49 |
|
50 |
BTW: I also use zswap, so tmpfs sits in front of a compressed |
51 |
write-back cache before being written out to swap compressed. This |
52 |
should generally be much more efficient (performance-wise) than putting |
53 |
/tmp on zram. |
54 |
|
55 |
I configured tmpfs for portage to use up to 30GB of space, which is |
56 |
almost twice the RAM I have. And it works because tmpfs is not required |
57 |
to be resident all the time: Inactive parts will be swapped out. The |
58 |
kernel handles this much similar to the page cache, with the difference |
59 |
that your files aren't backed by your normal file system but by swap. |
60 |
And swap has a lot lower IO overhead. |
61 |
|
62 |
Overall, having less IO overhead (and less head movement for portage |
63 |
builds) is a very very efficient thing to do. GCC constantly needs all |
64 |
sorts of files from your installation (libs for linking, header files, |
65 |
etc), and writes a lot of transient files which are needed once later |
66 |
and then discarded. There's no point in putting it on a non-transient |
67 |
file system. |
68 |
|
69 |
I use the following measures to get more performance out of this setup: |
70 |
|
71 |
* I have three swap partitions spread across three HDDs |
72 |
* I have a lot of swap space (60 GB) to have space for tmpfs |
73 |
* I have bcache in front of my HDD filesystem |
74 |
* I have a relatively big SSD dedicated to bcache |
75 |
|
76 |
My best recommendation is to separate swap and filesystem devices. |
77 |
While I didn't do it that way, I still separate them through bcache |
78 |
and thus decouple fs access and swap access although they are on the |
79 |
same physical devices. My bcache is big enough that most accesses would |
80 |
go to the SSD only. I enabled write-back to have that effect also for |
81 |
write access. |
82 |
|
83 |
If you cannot physically split swap from fs, a tmpfs setup for portage |
84 |
may not be recommended (except you have a lot of memory, like 16GB or |
85 |
above). But YMMV. |
86 |
|
87 |
Still, I recommend it for /tmp, especially if your system is on SSD. |
88 |
Unix semantics suggest that /tmp is not expected to survive reboots |
89 |
anyways (in contrast, /var/tmp is expected to survive reboots), so |
90 |
tmpfs is a logical consequence to use for /tmp. |
91 |
|
92 |
|
93 |
-- |
94 |
Regards, |
95 |
Kai |
96 |
|
97 |
Replies to list-only preferred. |