mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 ;)



      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®