1 |
On Friday 12 January 2007 12:27, Duncan <1i5t5.duncan@×××.net> wrote |
2 |
about '[gentoo-desktop] Re: CD player recommendations ??': |
3 |
> The thing is, however, that if it's read in from disk only to be written |
4 |
> out to the swap aka paging device |
5 |
|
6 |
No, it would be read in as normal, you'd never read in a page *just* to put |
7 |
it in swap. |
8 |
|
9 |
> Rather, the kernel just memory-maps the file in from its original |
10 |
> location, not even loading it into actual memory unless it's actually |
11 |
> needed. No load, only to turn around and write it back out to swap. |
12 |
|
13 |
Right I wasn't suggesting this change at all or that such a change would |
14 |
even have any real utility. |
15 |
|
16 |
> If |
17 |
> it IS loaded into memory because it's actually used, it's either going |
18 |
> to be used enough to keep it in cache most of the time, or it's not |
19 |
> going to be used all that much, |
20 |
|
21 |
...or the system is under memory pressure, that page is not locked or |
22 |
otherwise *currently* used by a process, AND the data has already been |
23 |
read from disk because it was used in the recent past either because it |
24 |
was mmap()ed and read by a process, or because it is in the filesystem |
25 |
cache. |
26 |
|
27 |
> and if the memory needs reclaimed, the |
28 |
> kernel simply dumps the physical memory without having to bother writing |
29 |
> it to swap since the file is memory-mapped directly on disk as it is. |
30 |
|
31 |
But, the kernel has a choice here. Either write to swap or not. If the |
32 |
kernel writes to swap, then the later read can come from swap *or* the |
33 |
original location *or* both in a pseudo-RAID-1 fashion. [Thus, even if |
34 |
the swap device is *slower* than the filesytem, you make the later, |
35 |
require operation to read back in the page faster.] |
36 |
|
37 |
> Swap would have to be several times (way more than twice) as fast in |
38 |
> ordered to even theoretically make it worth all those additional |
39 |
> still-slow I/O operations. |
40 |
|
41 |
If writing the page to swap then reading it back from swap (2 I/O |
42 |
operations) is faster than reading it from disk (1 I/O operation), then it |
43 |
would be better to write to swap. A rough estimate of when it would be |
44 |
better to write to swap when swap is approx. double the speed of the |
45 |
standard filesystem. (2 == 2 x 1). |
46 |
|
47 |
> It's also worth noting that it's a reasonable assumption that a company |
48 |
> or individual having enough money to do the fast striped RAID swap, |
49 |
> generally has enough money to buy a reasonable amount of memory as well, |
50 |
> thus avoiding routine operational use of swap. |
51 |
|
52 |
Why wouldn't they want to kernel to take advantage of that space to speed |
53 |
up operations? There's no advantage to having the kernel avoid the use of |
54 |
swap, since the kernel requires all that space to be exclusively allocated |
55 |
to it anyway. |
56 |
|
57 |
> While swap may be used |
58 |
> some, it's normally not going to be used enough to make the extra I/O |
59 |
> worth it to actually read the file in and then page it out to swap, just |
60 |
> so it's on the faster swap. |
61 |
|
62 |
Again, if you've already read the page in for some other operation, but |
63 |
need the RAM that currently contains it, the kernel has two options: write |
64 |
to swap or not. There are reasonable setups where the extra write |
65 |
operation will actually save time. There's not a *lot* of extra I/O |
66 |
involved, just twiddling some bits in the kernel tables, and requesting a |
67 |
page be written to a block device (the write need not finish before you do |
68 |
other things on the CPU) *one* (1) extra operation. |
69 |
|
70 |
-- |
71 |
"If there's one thing we've established over the years, |
72 |
it's that the vast majority of our users don't have the slightest |
73 |
clue what's best for them in terms of package stability." |
74 |
-- Gentoo Developer Ciaran McCreesh |