From: Johannes Weiner <hannes@cmpxchg.org>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Nick Piggin <npiggin@suse.de>,
Stewart Smith <stewart@flamingspork.com>
Subject: Re: RFC: mincore: add a bit to indicate a page is dirty.
Date: Mon, 11 Feb 2013 11:27:01 -0500 [thread overview]
Message-ID: <20130211162701.GB13218@cmpxchg.org> (raw)
In-Reply-To: <87a9rbh7b4.fsf@rustcorp.com.au>
On Mon, Feb 11, 2013 at 01:43:03PM +1030, Rusty Russell wrote:
> I am writing an app which really wants to know if a file is on the
> disk or not (ie. do I need to sync?).
When the page is under writeback, it's not necessarily on disk yet,
but you also don't need to sync. Which semantics make more sense?
I'm leaning toward checking both PG_dirty and PG_writeback.
> mincore() bits other than 0 are undefined (as documented in the man
> page); in fact my Ubuntu 12.10 i386 system seems to write 129 in some
> bytes, so it really shouldn't break anyone.
>
> Is PG_dirty the right choice? Is that right for huge pages? Should I
> assume is_migration_entry(entry) means it's not dirty, or is there some
> other check here?
If your only consequence of finding dirty pages is to sync, would you
be better off using fsync/fdatasync maybe?
This should work even if you only access the file through mmap, due to
the way we trap dirtying with write-protected ptes to accurately
account for dirty pages and update the status in the page cache.
> @@ -36,7 +39,15 @@ static void mincore_hugetlb_page_range(struct vm_area_struct *vma,
> */
> ptep = huge_pte_offset(current->mm,
> addr & huge_page_mask(h));
> - present = ptep && !huge_pte_none(huge_ptep_get(ptep));
> + if (ptep) {
> + pte_t pte = huge_ptep_get(ptep);
> +
> + if (!huge_pte_none(pte)) {
> + flags = MINCORE_INCORE;
> + if (pte_dirty(pte))
> + flags |= MINCORE_DIRTY;
> + }
> + }
This looks good to me. However, this only covers the hugetlb page
implementation, you also have to annotate mincore_huge_pmd to cover
transparent huge pages:
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 6001ee6..c632517 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1403,12 +1403,17 @@ int mincore_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
int ret = 0;
if (__pmd_trans_huge_lock(pmd, vma) == 1) {
+ struct page *page = pmd_page(pmd);
+ unsigned char flags;
/*
* All logical pages in the range are present
* if backed by a huge page.
*/
+ flags = MINCORE_INCORE;
+ if (PageDirty(page))
+ flags |= MINCORE_DIRTY;
spin_unlock(&vma->vm_mm->page_table_lock);
- memset(vec, 1, (end - addr) >> PAGE_SHIFT);
+ memset(vec, flags, (end - addr) >> PAGE_SHIFT);
ret = 1;
}
> @@ -131,14 +148,15 @@ static void mincore_pte_range(struct vm_area_struct *vma, pmd_t *pmd,
>
> if (is_migration_entry(entry)) {
> /* migration entries are always uptodate */
> - *vec = 1;
> + *vec = MINCORE_INCORE;
> + /* FIXME: Can they be dirty? */
Yes, they can. Use migration_entry_to_page() [safe with pte lock] and
test PageDirty() on it.
next prev parent reply other threads:[~2013-02-11 16:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-11 3:13 Rusty Russell
2013-02-11 16:27 ` Johannes Weiner [this message]
2013-02-11 22:12 ` Andrew Morton
2013-02-12 5:44 ` Rusty Russell
2013-02-15 6:34 ` [patch 1/2] mm: fincore() Johannes Weiner
2013-02-15 20:39 ` David Miller
2013-02-15 21:14 ` Andrew Morton
2013-02-15 22:28 ` Johannes Weiner
2013-02-15 22:34 ` Andrew Morton
2013-02-15 21:27 ` Andrew Morton
2013-02-15 23:13 ` Johannes Weiner
2013-02-15 23:42 ` Andrew Morton
2013-02-16 4:23 ` Rusty Russell
2013-02-17 22:51 ` Johannes Weiner
2013-02-17 22:54 ` Andrew Morton
2013-05-29 14:53 ` Andres Freund
2013-05-29 17:32 ` Johannes Weiner
2013-05-29 17:52 ` Andres Freund
2013-02-18 5:41 ` Rusty Russell
2013-02-19 10:25 ` Simon Jeons
2013-02-15 6:35 ` [patch 2/2] x86-64: hook up fincore() syscall Johannes Weiner
2013-02-12 5:49 ` RFC: mincore: add a bit to indicate a page is dirty Rusty Russell
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=20130211162701.GB13218@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=rusty@rustcorp.com.au \
--cc=stewart@flamingspork.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®