1 |
Volker Armin Hemmann wrote: |
2 |
> emm, no. |
3 |
|
4 |
Look, if you're not going to actually respond to something, then either |
5 |
don't reply or at least don't quote it. One-liners really aren't |
6 |
helpful - this isn't mean to be a flame-war over disk-fs vs disk-swap. |
7 |
I'm as interested as anybody to understand the pros/cons of both, but |
8 |
let's keep it civil and about finding answers, not beating our chests... |
9 |
|
10 |
> |
11 |
> Not real benchmarks. But kdepim with enablefinal, 1gb of ram and -j2 several |
12 |
> hours. With j1 2h. |
13 |
> . |
14 |
> kdepim with 2gb of ram and j2 30m |
15 |
> Just because first case swap storn, last case no swap at all. |
16 |
|
17 |
Well, sure. But that isn't apples to apples. And even with more RAM |
18 |
you might have a performance difference due to disk-thrashing. |
19 |
|
20 |
I'll see if I can do some benchmarking between disk and swap. |
21 |
|
22 |
> |
23 |
>> Again, tmpfs doesn't "reserve" memory - it uses memory - just like |
24 |
>> cache/buffers. |
25 |
> |
26 |
> but while cache/buffers can be discarded when the ram is needed, tmpfs has to |
27 |
> be shoved into butt-slow swap. |
28 |
|
29 |
It can only be discarded after it is flushed. Just like swap. The only |
30 |
difference is when the flushing occurs. With files the flushing happens |
31 |
right after a write, with swapping it happens when the memory is needed |
32 |
for something else. |
33 |
|
34 |
|
35 |
> |
36 |
>>>> I certainly agree that |
37 |
>>>> swap is slow compared to RAM, but it isn't slow compared to a disk-based |
38 |
>>>> filesystem. |
39 |
> |
40 |
> yes, yes it is. It is faster to start an app from disk, then to fetch it out |
41 |
> of swap. My very personal experience since many many years. |
42 |
> |
43 |
|
44 |
Uh, you do know that when you start an app from disk that the kernel |
45 |
just mmaps the file, right? Then any access to process memory triggers |
46 |
a page fault and the page is swapped in. When you start a program from |
47 |
disk it IS swapped to start with - the image on disk is just treated |
48 |
like a swap file and the same code is used to read it into memory as any |
49 |
other missing page. The same applies to any other use of mmap. If you |
50 |
go back "many many" years the behavior might have been different, but it |
51 |
has been this way for a while. |
52 |
|
53 |
> |
54 |
> your system would feel and act a lot faster if you don't have anything in |
55 |
> swap. 'Fine' is good - as long as you don't know the alternative. |
56 |
|
57 |
How do you know? What is in the swap? Maybe it is just pages with |
58 |
memory leaks. If it is never read why would the system be slower? I |
59 |
wouldn't say that performance is any better after a reboot when swap is |
60 |
empty. |
61 |
|
62 |
>> Sure. Compared to about $1 for 2GB of hard drive space 30 euros is |
63 |
>> significant. |
64 |
> |
65 |
> don't forget that ram is also roughly 100 times faster than harddisk. |
66 |
|
67 |
Absolutely. If I wanted the fastest computer possible I'd have way more |
68 |
RAM (and CPU) than I have now. However, my finances aren't unlimited, |
69 |
and I'd rather make the most of what I have than just throw cash at |
70 |
problems. And if I did have more RAM I'd still want to make the most of it. |
71 |
|
72 |
> |
73 |
> you could stop shoving everything in swap - no costs involved and system is a |
74 |
> lot faster. |
75 |
> |
76 |
|
77 |
Ok, it is obvious that absent benchmarks that nobody is convincing |
78 |
anybody here. I think that most with a good knowledge of the linux |
79 |
kernel would disagree with you. I don't profess to have that level of |
80 |
expertise, but I don't see anything being posted by you which indicates |
81 |
why swap should be slower than filesystem access, other than just a |
82 |
general statement that swap is "butt slow". |
83 |
|
84 |
If I can come up with some measurements I'll post them. My intent isn't |
85 |
really to get into a "he said she said" over this. I'd like to inform |
86 |
and be informed, and I'm interested in all experiences although anecdote |
87 |
is obviously very limited. |