[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH V4 01/13] netback: page pool version 1
On Fri, 2012-02-17 at 19:19 +0000, Konrad Rzeszutek Wilk wrote: > > > > Hmm, this kind of stuff should be discussed on lkml. > > > > I doubt we want yet another memory allocator, with a global lock > > (contended), and no NUMA properties. > > That should be fixed. Are there any existing memory pools that could be used > instead? I (And I think everybody) is all for using the existing APIs if they > can do the job. I was lookign a bit at the dmapool code, but that requires > something > we don't have - the 'struct device'. We could manufacture a fake one, but > that just > stinks of hack. > I've been thinking about this for a long time, so any recommendation is welcomed. It is not my intention to write yet another memory allocator. What I need is a data structure to track pages owned by netback. Let me state the requirements of this data structure: 1. limits overall memory used by all vifs (this could also be met by the underlying allocator) 2. provides function to tell whether a particular page is mapped from foreign domain -- is_in_pool() is a surrogate for that 3. provides function to back-reference owner vif of the page To achieve requirement 2, page pool manipulates page->mapping field. To achieve requirement 3, page pool maintains idx <-> vif relationship internally. I think I can use mempool internally for page allocation. But I still need a data structure to meet other requirements. > It [pagepool] also should use the shrinker API I think. This is doable, but let's make everybody happy with the page pool design and implementation first. Wei. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |