From: Arjan van de Ven <arjan@infradead.org>
To: Kimball Murray <kmurray@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Dirty page tracking patch
Date: Mon, 11 Jul 2005 20:28:09 +0200 [thread overview]
Message-ID: <1121106489.3177.36.camel@laptopd505.fenrus.org> (raw)
In-Reply-To: <42D2B774.5080409@redhat.com>
> >
> >is the stratus code entirely open source/GPL ? (I assume it is since you
> >EXPORT_SYMBOL_GPL and also use other similar stuff). If so.. could you
> >post an URL to that? It's customary to do so when you post interface
> >patches for review so that the users of the interfaces can be seen, and
> >thus the interface better reviewed.
> >
> I don't have access to a Stratus web server where I could post the code,
> since I'm currently sitting at a Redhat desk :) So if you'll indulge
> me, I'll attach the harvest code to this note. The harvest code is one
> component of a GPL'd kernel module. The harvest component is the only
> one that interacts with the dirty page tracking patch. Other parts of
> the module do PCI-hotplug related things that are specific to our platform.
ok so your entire kernel side stack is GPL? Good.
> >
> >+#define mm_track(ptep)
> >
> >you have to make that a do { ; } while (0) define as per kernel
> >convention/need
> >
> >also you now make set_pte() and co more than trivial assignments, please
> >convert them to inlines so that typechecking is performed and no double
> >evaluation of arguments is done!
> >(this is a real problem for code that would do set_pte(pte++, value) in
> >a loop or so)
> >
> thanks, I'll make those changes and re-build/re-test/re-post.
>
> >- if (!pte_dirty(*ptep))
> >- return 0;
> >- return test_and_clear_bit(_PAGE_BIT_DIRTY, &ptep->pte_low);
> >+ mm_track(ptep);
> >+ return (test_and_clear_bit(_PAGE_BIT_DIRTY,
> >&ptep->pte_low) |
> >+ test_and_clear_bit(_PAGE_BIT_SOFTDIRTY,
> >&ptep->pte_low));
> > }
> >
> >
> >are you sure you're not introducing a race condition there?
> >and if you're sure, why do you need 2 atomic ops in sequence?
> >
> I think we're OK there. That code only appears in the sys_msync path
> (sync_page_range), after the page table lock is taken. The only code
> that moves hardware dirty bits to software dirty bits is in the harvest
> itself (attached). And that code runs with all other cpus parked.
then you didn't answer my question about why the lock; atomic bit is
needed ;)
prev parent reply other threads:[~2005-07-11 18:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-11 13:16 Kimball Murray
2005-07-11 13:35 ` Arjan van de Ven
2005-07-11 18:16 ` Kimball Murray
2005-07-11 18:28 ` Arjan van de Ven [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=1121106489.3177.36.camel@laptopd505.fenrus.org \
--to=arjan@infradead.org \
--cc=kmurray@redhat.com \
--cc=linux-kernel@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 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®