From: Russell King <rmk@arm.linux.org.uk>
To: marcelo@conectiva.com.br (Marcelo Tosatti)
Cc: torvalds@transmeta.com (Linus Torvalds),
alan@lxorguk.ukuu.org.uk (Alan Cox),
gniibe@m17n.org (NIIBE Yutaka),
linux-kernel@vger.kernel.org (lkml)
Subject: Re: [PATCH] swapin flush cache bug
Date: Tue, 13 Feb 2001 09:50:42 +0000 (GMT) [thread overview]
Message-ID: <200102130950.f1D9ohq01768@flint.arm.linux.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.21.0102122107550.29855-100000@freak.distro.conectiva> from "Marcelo Tosatti" at Feb 12, 2001 09:21:55 PM
Marcelo Tosatti writes:
> If lookup_swap_cache() finds a page in the swap cache, and that page was
> in memory because of the swapin readahead, the cache is not flushed.
>
> Here is a patch to fix the problem by always flushing the cache including
> for pages in the swap cache:
> -
> - flush_page_to_ram(page);
> - flush_icache_page(vma, page);
> }
>
> mm->rss++;
> +
> + flush_page_to_ram(page);
> + flush_icache_page(vma, page);
Surely if the page is in the swap cache, we don't need the
flush_page_to_ram() because the data is already written to the page. Yes,
there may be some reminents of it in the cache due to it being written
to disk via PIO.
Thinking about it some more - we have a process. It used to contain page
P at address V. We unmapped the page (and did the right thing with the
caches). Now, something wants to access address V, so we pull the page
from the swap cache, and place page P back at address V. We therefore
shouldn't need any cache manipulation at this point.
What was the problem? The old code seems to behave well on a virtual
address indexed virtual address tagged cache.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
next prev parent reply other threads:[~2001-02-13 9:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-12 23:21 Marcelo Tosatti
2001-02-13 9:50 ` Russell King [this message]
2001-02-13 10:53 ` NIIBE Yutaka
2001-02-13 11:16 ` Russell King
2001-02-13 11:26 ` Alan Cox
2001-02-13 23:50 ` NIIBE Yutaka
2001-02-14 2:08 ` NIIBE Yutaka
2001-02-14 10:12 ` Marcelo Tosatti
2001-06-27 0:51 ` NIIBE Yutaka
2001-06-27 10:11 ` Marcelo Tosatti
2001-06-28 0:42 ` David S. Miller
2001-06-28 0:07 ` NIIBE Yutaka
2001-06-27 22:41 ` Marcelo Tosatti
2001-06-28 0:23 ` Stephen C. Tweedie
2001-06-28 0:47 ` David S. Miller
2001-06-28 1:10 ` David S. Miller
2001-06-29 14:18 ` NIIBE Yutaka
2001-07-02 22:47 ` Cache issues David S. Miller
2001-06-28 0:41 ` [PATCH] swapin flush cache bug NIIBE Yutaka
2001-06-28 1:04 ` NIIBE Yutaka
2001-07-02 11:23 ` Cache issues NIIBE Yutaka
2001-07-03 0:04 ` NIIBE Yutaka
2001-06-28 0:46 ` [PATCH] swapin flush cache bug David S. Miller
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=200102130950.f1D9ohq01768@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=gniibe@m17n.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
--cc=torvalds@transmeta.com \
/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
all inboxes | Powered by JetHome®