[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-desktop
Subject:    Re: [gentoo-desktop]  Re: CD player recommendations ??
From:       "Boyd Stephen Smith Jr." <bss03 () volumehost ! net>
Date:       2007-01-12 23:48:10
Message-ID: 200701121748.21530.bss03 () volumehost ! net
[Download RAW message or body]

On Friday 12 January 2007 12:27, Duncan <1i5t5.duncan@cox.net> wrote 
about '[gentoo-desktop]  Re: CD player recommendations ??':
> The thing is, however, that if it's read in from disk only to be written
> out to the swap aka paging device

No, it would be read in as normal, you'd never read in a page *just* to put 
it in swap.

> Rather, the kernel just memory-maps the file in from its original
> location, not even loading it into actual memory unless it's actually
> needed.  No load, only to turn around and write it back out to swap.

Right I wasn't suggesting this change at all or that such a change would 
even have any real utility.

> If 
> it IS loaded into memory because it's actually used, it's either going
> to be used enough to keep it in cache most of the time, or it's not
> going to be used all that much,

...or the system is under memory pressure, that page is not locked or 
otherwise *currently* used by a process, AND the data has already been 
read from disk because it was used in the recent past either because it 
was mmap()ed and read by a process, or because it is in the filesystem 
cache.

> and if the memory needs reclaimed, the 
> kernel simply dumps the physical memory without having to bother writing
> it to swap since the file is memory-mapped directly on disk as it is. 

But, the kernel has a choice here.  Either write to swap or not.  If the 
kernel writes to swap, then the later read can come from swap *or* the 
original location *or* both in a pseudo-RAID-1 fashion.  [Thus, even if 
the swap device is *slower* than the filesytem, you make the later, 
require operation to read back in the page faster.]

> Swap would have to be several times (way more than twice) as fast in
> ordered to even theoretically make it worth all those additional
> still-slow I/O operations.

If writing the page to swap then reading it back from swap (2 I/O 
operations) is faster than reading it from disk (1 I/O operation), then it 
would be better to write to swap.  A rough estimate of when it would be 
better to write to swap when swap is approx. double the speed of the 
standard filesystem. (2 == 2 x 1).

> It's also worth noting that it's a reasonable assumption that a company
> or individual having enough money to do the fast striped RAID swap,
> generally has enough money to buy a reasonable amount of memory as well,
> thus avoiding routine operational use of swap.

Why wouldn't they want to kernel to take advantage of that space to speed 
up operations?  There's no advantage to having the kernel avoid the use of 
swap, since the kernel requires all that space to be exclusively allocated 
to it anyway.

> While swap may be used 
> some, it's normally not going to be used enough to make the extra I/O
> worth it to actually read the file in and then page it out to swap, just
> so it's on the faster swap.

Again, if you've already read the page in for some other operation, but 
need the RAM that currently contains it, the kernel has two options: write 
to swap or not.  There are reasonable setups where the extra write 
operation will actually save time.  There's not a *lot* of extra I/O 
involved, just twiddling some bits in the kernel tables, and requesting a 
page be written to a block device (the write need not finish before you do 
other things on the CPU) *one* (1) extra operation.

-- 
"If there's one thing we've established over the years,
it's that the vast majority of our users don't have the slightest
clue what's best for them in terms of package stability."
-- Gentoo Developer Ciaran McCreesh

[Attachment #3 (application/pgp-signature)]
-- 
gentoo-desktop@gentoo.org mailing list


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic