On Sat, 2013-01-26 at 18:54 -0800, Hugh Dickins wrote: > On Sat, 26 Jan 2013, Simon Jeons wrote: > > On Fri, 2013-01-25 at 17:54 -0800, Hugh Dickins wrote: > > > From: Petr Holasek <phola...@redhat.com> > > > @@ -1122,6 +1166,18 @@ struct rmap_item *unstable_tree_search_i > > > return NULL; > > > } > > > > > > + /* > > > + * If tree_page has been migrated to another NUMA node, it > > > + * will be flushed out and put into the right unstable tree > > > > Then why not insert the new page to unstable tree during page migration > > against current upstream? Because default behavior is merge across > > nodes. > > I don't understand the words "against current upstream" in your question.
I mean current upstream codes without numa awareness. :) > > We cannot move a page (strictly, a node) from one tree to another during > page migration itself, because the necessary ksm_thread_mutex is not held. > Not would we even want to while "merge across nodes". > > Ah, perhaps you are pointing out that in current upstream, the only user > of ksm page migration is memory hotremove, which in current upstream does > hold ksm_thread_mutex. > > So you'd like us to add code for moving a node from one tree to another > in ksm_migrate_page() (and what would it do when it collides with an Without numa awareness, I still can't understand your explanation why can't insert the node to the tree just after page migration instead of inserting it at the next scan. > existing node?), code which will then be removed a few patches later > when ksm page migration is fully enabled? > > No, I'm not going to put any more thought into that. When Andrea pointed > out the problem with Petr's original change to ksm_migrate_page(), I did > indeed think that we could do something cleverer at that point; but once > I got down to trying it, found that a dead end. I wasn't going to be > able to test the hotremove case properly anyway, so no good pursuing > solutions that couldn't be generalized. > > Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
