WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH 3/3] mm: Extend memory hotplug API to allow memor

On Mon, Mar 28, 2011 at 03:37:35PM -0700, Andrew Morton wrote:
> On Mon, 28 Mar 2011 11:25:07 +0200
> Daniel Kiper <dkiper@xxxxxxxxxxxx> wrote:
> > +/*
> > + * 0 priority makes this the fallthrough default. All
> > + * architectures wanting to override this should set
> > + * a higher priority and return NOTIFY_STOP to keep
> > + * this from running.
> > + */
> > +
> > +static struct notifier_block generic_online_page_nb = {
> > +   .notifier_call = generic_online_page_notifier,
> > +   .priority = 0
> > +};
> > +
> > +static int __init init_online_page_chain(void)
> > +{
> > +   return register_online_page_notifier(&generic_online_page_nb);
> > +}
> > +pure_initcall(init_online_page_chain);
> > +
> > +static void online_page(struct page *page)
> > +{
> > +   raw_notifier_call_chain(&online_page_chain, 0, page);
> > +}
>
> This is a bit strange.  Normally we'll use a notifier chain to tell
> listeners "hey, X just happened".  But this code is different - it
> instead uses a notifier chain to tell handlers "hey, do X".  Where in
> this case, X is "free a page".
>
> And this (ab)use of notifiers is not a good fit!  Because we have the
> obvious problem that if there are three registered noftifiers, we don't
> want to be freeing the page three times.  Hence the tricks with
> notifier callout return values.
>
> If there are multiple independent notifier handlers, how do we manage
> their priorities?  And what are the effects of the ordering of the
> registration calls?
>
> And when one callback overrides an existing one, is there any point in
> leaving the original one installed at all?
>
> I dunno, it's all a bit confusing and strange.  Perhaps it would help
> if you were to explain exactly what behaviour you want here, and we can
> look to see if there is a more idiomatic way of doing it.

OK. I am looking for simple generic mechanism which allow runtime
registration/unregistration of generic or module specific (in that
case Xen) page onlining function. Dave Hansen sugested compile time
solution (https://lkml.org/lkml/2011/2/8/235), however, it does not
fit well in my new project on which I am working on (I am going post
details at the end of April).

> Also...  I don't think we need (the undocumented)
> OP_DO_NOT_INCREMENT_TOTAL_COUNTERS and OP_INCREMENT_TOTAL_COUNTERS.
> Just do
>
> void __online_page_increment_counters(struct page *page,
>                                       bool inc_total_counters);
>
> and pass it "true" or false".

What do you think about __online_page_increment_counters()
(totalram_pages and totalhigh_pages) and
__online_page_set_limits() (num_physpages and max_mapnr) ???

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel