Messages in this thread | | | Subject | Re: [PATCH 5 of 6] hotplug-memory: add section_ops | From | Dave Hansen <> | Date | Thu, 03 Apr 2008 18:52:58 -0700 |
| |
On Thu, 2008-04-03 at 18:12 -0700, Jeremy Fitzhardinge wrote: > Dave Hansen wrote: > > On Thu, 2008-04-03 at 17:05 -0700, Jeremy Fitzhardinge wrote: > > I think it might just be nicer to have a global list of these handlers > > somewhere. The Xen driver can just say "put me on the list of > > callbacks" and we'll call them at online_page(). I really don't think > > we need to be passing an ops structure around. > > > > Yes, but it seems a bit awkward. If we assume that: > > 1. Xen will be the only user of the hook, and > 2. Xen-balloon hotplug is exclusive of real memory hotplug > > then I guess its reasonable (though if that's the case it would be > simpler to just put a direct call under #ifdef CONFIG_XEN_BALLOON in there).
Yeah, I'm OK with something along those lines, too. I'd prefer sticking some stubs in a header and putting the #ifdef there, if only for aesthetic reasons.
> But if we think there can be multiple callbacks, and they all get called > on the online of each page, and there can be multiple kinds of hotplug > memory it gets pretty messy. Each has to determine "why was I called on > this page?" and you'd to work out which one actually does the job of > onlining. It just seems cleaner to say "this section needs to be > onlined like this", and there's no ambiguity.
I really wish we'd stop calling it "page online". :)
Let me think out loud for a sec here. Here's how memory hotplug works in a nutshell:
First step (add_memory() or probe time): 1. get more memory made available 2. create kva mapping for that memory (for lowmem) 3. allocate 'struct pages'
Second step, 'echo 1 > .../memoryXXX/online' time: 4. modify zone/pgdat spans (make the VM account for the memory) 5. Initialize the 'struct page' 6. free the memory into the buddy allocator
You can't do (2) because Xen doesn't allow mappings to be created until real backing is there. You've already done this, right?
You don't want to do (6) either, because there is no mapping for the page and it isn't committed in hardware, yet, so you don't want someone grabbing it *out* of the buddy allocator and using it.
Your solution is to take those first 1-5 steps, and had the balloon driver call them directly. The online_page() modifications are because 5/6 are a bit intertwined right now. Are we on the same page so far?
Why don't we just free the page back into the balloon driver? Take the existing steps 1-5, use them as they stand today, and just chop of step 6 for Xen. It'd save a bunch of this code churn and also stop us from proliferating any kind of per-config section-online behavior like you're asking about above.
That might also be generalizable to anyone else that wants the "fresh meat" newly-hotplugged memory. Large page users might be other consumers here.
> I'm already anticipating using the ops mechanism to support another > class of Xen hotplug memory for managing large pages.
Do tell. :)
-- Dave
| |