From: Joseph A Knapka <jknapka@earthlink.net>
To: Amol Kumar Lad <amolk@ishoni.com>
Cc: Martin Maletinsky <maletinsky@scs.ch>,
linux-mm@kvack.org, kernelnewbies@nl.linux.org
Subject: Re: Question on swapping
Date: Thu, 12 Dec 2002 08:56:24 -0700 [thread overview]
Message-ID: <3DF8B1A8.1080303@earthlink.net> (raw)
In-Reply-To: <1039224592.4551.57.camel@amol.in.ishoni.com>
Amol Kumar Lad wrote:
>For the first time P would never be found in the swap cache, infact
> try_to_swap_out shall do following
> a] Page is dirty (in page table entry), so set PG_DIRTY in struct page
This appears to be the *only* place in the kernel where pte dirty
bits are propagated into the mem_map.
> b] Allocate a swap entry and add this page to swap cache
> c] release the page, and add the modify page table entry to point it to
> swap entry
>
> Now We have
> a] Page table entry for P contains swap info
> b] Page P in swap cache
> c] PG_DIRTY _is_ set (infact for a page in swap cache this is always
> true)
>
> Do remember, along with the swap cache P may be party of inactive_dirty
> list.
>
> The actual swapping to backing store is done by page scanner.
> It shall do following. Assume it has decided to _really_ free P
> 1] As page is dirty, call the page write back function. Thus here for
> the first time page found its place in swap.
> 2] send P back home, to buddy allocator
>
> If process A again access the page, then page fault handler shall do
> following
> 1] allocate a swap cache page
> 2] read the page from swap.
> 3] Modify page table entry of A to point to this page
So now the page is not marked dirty in the mem_map. What if A *now*
writes the page and then tries to swap it out? That's Martin's question:
in that case, we have a page that's in the swap cache; whose
page struct is *not* marked dirty; but which *is* actually dirty.
How do we know the page will be kept up to date on disk?
I used to understand how this worked, but I've forgotten. Or
maybe I never really understood it.
Cheers,
-- Joe
--
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/
prev parent reply other threads:[~2002-12-12 15:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-04 15:17 Martin Maletinsky
2002-12-05 19:08 ` Joseph A Knapka
2002-12-06 9:45 ` Martin Maletinsky
2002-12-07 1:29 ` Amol Kumar Lad
2002-12-12 15:56 ` Joseph A Knapka [this message]
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=3DF8B1A8.1080303@earthlink.net \
--to=jknapka@earthlink.net \
--cc=amolk@ishoni.com \
--cc=kernelnewbies@nl.linux.org \
--cc=linux-mm@kvack.org \
--cc=maletinsky@scs.ch \
/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