Messages in this thread | | | Subject | Re: [patch 2] Xen core patch : arch_free_page return value | Date | Thu, 18 Nov 2004 08:35:57 +0000 | From | Keir Fraser <> |
| |
> > Pages that have been allocated by our custom allocators get passed > > into standard linux subsystems where we get no control over how > > they're freed. > > OK, then how are they allocated? Are they only allocated by your > special drivers or in your architecture?
Yes, they are only allocated within our own code. I use "allocation" loosely here -- in the case of our network backend driver, the page fragments that we pass into the network subsystem are actually temporary mappings of other domains' RAM -- not allocated from this kernel's heap at all.
> I think allowing this is weird: > > foo = special_zen_malloc(); > bar = kmalloc(); > kfree(foo); > kfree(bar); > > Shoudn't it be > > special_zen_free(free);?
We don't hook into the slab allocator, but into the page_alloc zoned buddy allocator: so in your example replace kmalloc() with get_free_page(), and kfree() with free_page(). The point is that we can't always use 'special_xen_free_page()' because the page's refcnt may fall to zero within a generic Linux subsystem (e.g., the network stack). So we need to be able to hook of free_page().
It would be great if we could have a "destructor hook" per page that points at the relevant heap-free function to use, but that'd never fly here. This is the best we can do with absolutely minimal source impact, and no run-time impact on other arches.
> BTW, your arch-specific definition of PG_foreign is a little goofy. If > you need the bit, then put it in page-flags.h now. The memory hotplug > people have an evil plan to consume all unused bits in page->flags > (determined at compile-time) and that little gem will certainly break > it.
The whole of our foreign_page.h was in page-flags.h. Do you think the whole lot should go back, or just the bit definition?
> It's great that you contained stuff to your architecture, but little > bits like the page-flags thing don't make me think you've done it for > real, only hacked around it :)
We hacked around it in this case because the PageForeign stuff was entirely within page_alloc.c and page-flags.h. Since only Xen used it we were asked if we could have less non-arch source impact and this is what we came up with. :-) Point taken on PG_foreign though.
-- Keir - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |