1 |
Rich Freeman wrote: |
2 |
> On Thu, Feb 8, 2018 at 2:17 PM, Dale <rdalek1967@×××××.com> wrote: |
3 |
>> As someone else pointed out, if you |
4 |
>> start using swap, that generally defeats the purpose of tmpfs. |
5 |
>> |
6 |
> I'll just add one thing to this, which I've probably already said ages ago: |
7 |
> |
8 |
> In an ideal world swap would STILL be better than building on disk, |
9 |
> because it gives the kernel fewer constraints around what gets written |
10 |
> to disk. |
11 |
> |
12 |
> Anything written to disk MUST end up on the disk within the dirty |
13 |
> writeback time limit. Anything written to tmpfs doesn't ever have to |
14 |
> end up on disk, and if it is swapped the kernel need not do it in any |
15 |
> particular timeframe. Also, the swapfile doesn't need the same kinds |
16 |
> of integrity features as a filesystem, which probably lowers the cost |
17 |
> of writes somewhat (if nothing else after a reboot there is no need to |
18 |
> run tmpreaper on it). |
19 |
> |
20 |
> So, swapping SHOULD still be better than building on disk, because any |
21 |
> object file that doesn't end up being swapped is a saved disk IO, and |
22 |
> the stuff that does get swapped will hopefully get written at a more |
23 |
> opportune time vs forcing the kernel to stop what is doing after 30s |
24 |
> (by default) to make sure that something gets written no matter what |
25 |
> (if it wasn't deleted before then). |
26 |
> |
27 |
> That's all in an ideal world. In practice I've never found the kernel |
28 |
> swapping algorithms to be the best in the world, and I've seen a lot |
29 |
> of situations where it hurts. I run without a swapfile for this |
30 |
> reason. It pains me to do it because I can think of a bunch of |
31 |
> reasons why this shouldn't help, and yet for whatever reason it does. |
32 |
> |
33 |
|
34 |
|
35 |
In my experience, once swap starts getting used, it gets slow, sometimes |
36 |
to the point that a response may take several seconds or more. When I |
37 |
compile without tmpfs at all, which means everything is on disk, it's |
38 |
rare that I can even tell it is using that IO for the drive. Every once |
39 |
in a while I may see a slight delay but not by much. The worst offender |
40 |
when I do see it, libreoffice. As we all know, that is one beast of a |
41 |
package. I don't recall having problems with web browsers, yet. Give |
42 |
it time tho. ;-) |
43 |
|
44 |
While you may have a point in some situations, here, it just doesn't |
45 |
work that way. As we all know tho, even if we all had the same |
46 |
settings, different systems are going to work differently because of |
47 |
some difference we may not be aware of. The mileage will vary for sure. |
48 |
|
49 |
I might add, over the years I've changed settings to adapt my system to |
50 |
give me the best response. However, if a person built a system with |
51 |
very little differences hardware and maybe even software wise, they |
52 |
could still run into something different and want different settings. |
53 |
The catch is, take advice from different folks and weigh all the |
54 |
options, then test things to see what works best. It may be that one |
55 |
part of your post helps, another part from mine, another part from |
56 |
someone else and in the end, it leaves settings that work. Well, on |
57 |
that system and for that person at least. ;-) |
58 |
|
59 |
Dale |
60 |
|
61 |
:-) :-) |