From: Nathan Dietsch <njd@ndietsch.com>
To: Mark Hahn <hahn@physics.mcmaster.ca>, linux-raid@vger.kernel.org
Subject: Re: RAID5 crash and burn
Date: Mon, 01 Nov 2004 19:58:01 +1100 [thread overview]
Message-ID: <4185FA99.9070101@ndietsch.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0411010106290.17633-100000@coffee.psychology.mcmaster.ca>
Mark,
Mark Hahn wrote:
>> From Understanding the Linux Kernel "Every access by a program to a
>>page that is swapped out increases the process execution time by an
>>order of magnitude. In short, if performance is of great importance,
>>swapping should be considered as a last resort." (p. 529)
>>
>>
>
>not relevant: we're talking about what it costs to perform
>a swapout, not what happens if the wrong page is chosen for
>swapout, and later necessitates a swapin.
>
>
You have convinced me that swapping out is low-overhead in Linux.
>
>
>>I agree that the write is cheap compared to the read (where you will
>>stall), but what is the purpose of writing something to swap if you do
>>not plan to read it again?
>>
>>
>
>to free the underlying physical page for other use.
>
>
Unused memory is wasted memory, hence the reason for FS caches.
If you have such a squeeze on memory that you are swapping for a more
active page using LRU algorithms, you do not have enough memory for the
task at hand.
>>>let me put it a completely other way: swap outs are normal, fairly
>>>frequent, and GOOD for performance.
>>>
>>>
>>>
>>Please explain how swapping out a page is good for performance.
>>
>>
>
>swapouts mean that the kernel doesn't need to dedicate a page of
>physical memory to keep track of some stale page. swapping out
>active pages would be mistake, obviously. the kernel tries to
>avoid that mistake in any OS.
>
>
Agreed, but yet again it comes back to not having enough memory for
*performance*.
>
>
>>I understand that unused pages are paged out, but how does this improve
>>performance beyond making more room for the FS cache?
>>
>>
>
>a swapout frees a physical page, period. whether it's used for
>the FS cache or not is irrelevant. perhaps your model for how
>the system works involves uniform references to all pages?
>if that were true, then indeed, swapouts would be dubious.
>since references are highly skewed, there are some pages which
>are not effective investments of physical ram, so to speak,
>but which can't be thrown away (because they're dirty and/or anonymous).
>
>
>
>>I am simply saying that comparing RAID5 and RAID1 for the purposes of
>>swapping is irrelevant, because if you are relying on the performance of
>>your swap device, you are missing the point that you have run out of
>>memory.
>>
>>
>
>which is either vapid or wrong. yes, it's silly to worry about
>how fast your system thrashes. but no one is talking about non-fatal error
>conditions like thrashing. and there *is* a good reason to choose
>r1 over r5 for swap, since writes are so much lower-overhead. worrying
>about the efficiency of r1 vs r5 reads verges on the "optimizing
>for thrashing" that you're so worried about.
>
>
That is what I was getting at.
I think this is going in circles, but it has made me see swapping in
another light.
Regards,
Nathan
next prev parent reply other threads:[~2004-11-01 8:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-31 4:59 RAID5 crash and burn coreyfro
2004-10-31 5:18 ` Guy
2004-10-31 9:59 ` coreyfro
2004-10-31 11:26 ` Robin Bowes
2004-10-31 17:19 ` coreyfro
2004-10-31 13:15 ` Guy
2004-10-31 13:54 ` Nathan Dietsch
2004-10-31 19:41 ` Mark Hahn
2004-11-01 4:26 ` Nathan Dietsch
2004-11-01 5:29 ` Mark Hahn
2004-11-01 6:05 ` Nathan Dietsch
2004-11-01 6:32 ` Mark Hahn
2004-11-01 7:01 ` Guy
2004-11-01 9:01 ` Nathan Dietsch
2004-11-01 8:58 ` Nathan Dietsch [this message]
2004-10-31 19:05 ` Michael Robinton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4185FA99.9070101@ndietsch.com \
--to=njd@ndietsch.com \
--cc=hahn@physics.mcmaster.ca \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.