From: Con Kolivas <kernel@kolivas.org>
To: Jan Knutar <jk-lkml@sci.fi>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
ck@vds.kolivas.org
Subject: Re: [PATCH] mm: yield during swap prefetching
Date: Wed, 8 Mar 2006 19:39:23 +1100 [thread overview]
Message-ID: <200603081939.23791.kernel@kolivas.org> (raw)
In-Reply-To: <200603080951.38316.jk-lkml@sci.fi>
On Wednesday 08 March 2006 18:51, Jan Knutar wrote:
> On Wednesday 08 March 2006 03:28, Con Kolivas wrote:
> > Anything that does disk access delays prefetch fine. Things that only do
> > heavy cpu do not delay prefetch. Anything reading from disk will be
> > noticeable during 3d gaming.
>
> What exactly makes the disk accesses noticeable? Is it because they steal
> time from the disk that the game otherwise would need, or do the disk
> accesses themselves consume noticeable amounts of CPU time?
> Or, do bits of the game's executable drop from memory to make room for the
> new stuff being pulled in from memory, causing the game to halt while it
> waits for its pages to come back? On a related note, through advanced use
> of handwaving and guessing, this seems to be the thing that kills my destop
> experience (*buzzword alert*) most often. Checksumming a large file seems
> to be less of an impact than things that seek alot, like updatedb.
>
> I remember playing vegastrike on my linux desktop machine few years ago,
> the game leaked so much memory that it filled my 2G swap rather often,
> unleashing OOM killer mayhem. I "solved" this by putting swap on floppy at
> lower priority than the 2G, and a 128M swap file as "backup" at even lower
> priority than the floppy. I didn't notice the swapping to harddrive, but
> when it started to swap to floppy, it made the game run a bit slower for a
> few seconds, plus the floppy light went on, and I knew I had 128M left to
> save my position and quit.
>
> If I needed floppy to make disk access noticeable on my very low end
> machine... What are these new fancy things doing to make HD access
> noticeable?
It's the cumulative effect of the cpu used by the in kernel code paths and the
kprefetchd kernel thread. Even running ultra low priority, if they read a lot
from the hard drive it costs us cpu time (seen as I/O wait in top for
example). Swap prefetch _never_ displaces anything from ram; it only ever
reads things from swap if there is generous free ram available. Not only that
but if it reads something from swap it is put at the end of the "least
recently used" list meaning that if _anything_ needs ram, these are the first
things displaced again.
Cheers,
Con
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-03-08 8:39 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-07 23:13 Con Kolivas
2006-03-07 23:26 ` Andrew Morton
2006-03-07 23:32 ` Con Kolivas
2006-03-08 0:05 ` Andrew Morton
2006-03-08 0:51 ` Con Kolivas
2006-03-08 1:11 ` Andrew Morton
2006-03-08 1:12 ` Con Kolivas
2006-03-08 1:19 ` Con Kolivas
2006-03-08 1:23 ` Andrew Morton
2006-03-08 1:28 ` Con Kolivas
2006-03-08 2:08 ` Lee Revell
2006-03-08 2:12 ` Con Kolivas
2006-03-08 2:18 ` Lee Revell
2006-03-08 2:22 ` Con Kolivas
2006-03-08 2:27 ` Lee Revell
2006-03-08 2:30 ` Con Kolivas
2006-03-08 2:52 ` [ck] " André Goddard Rosa
2006-03-08 3:03 ` Lee Revell
2006-03-08 3:05 ` Con Kolivas
2006-03-08 21:07 ` Zan Lynx
2006-03-08 23:00 ` Con Kolivas
2006-03-08 23:48 ` Zan Lynx
2006-03-09 0:07 ` Con Kolivas
2006-03-09 3:13 ` Zan Lynx
2006-03-09 4:08 ` Con Kolivas
2006-03-09 4:54 ` Lee Revell
2006-03-08 7:51 ` Jan Knutar
2006-03-08 8:39 ` Con Kolivas [this message]
2006-03-09 8:57 ` Helge Hafting
2006-03-09 9:08 ` Con Kolivas
2006-03-09 22:44 ` Peter Williams
2006-03-10 9:01 ` [ck] " Andreas Mohr
2006-03-10 9:11 ` Con Kolivas
2006-03-10 0:58 ` Peter Williams
2006-03-08 22:24 ` Pavel Machek
2006-03-09 2:22 ` Nick Piggin
2006-03-09 2:30 ` Con Kolivas
2006-03-09 2:57 ` Nick Piggin
2006-03-09 9:11 ` Con Kolivas
2006-03-08 13:36 ` [ck] " Con Kolivas
2006-03-17 9:06 ` Ingo Molnar
2006-03-08 8:48 ` Andreas Mohr
2006-03-08 8:52 ` Con Kolivas
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=200603081939.23791.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=akpm@osdl.org \
--cc=ck@vds.kolivas.org \
--cc=jk-lkml@sci.fi \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox