[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
Le jeudi 02 fÃvrier 2012 Ã 16:49 +0000, Wei Liu a Ãcrit : > A global page pool. Since we are moving to 1:1 model netback, it is > better to limit total RAM consumed by all the vifs. > > With this patch, each vif gets page from the pool and puts the page > back when it is finished with the page. > > This pool is only meant to access via exported interfaces. Internals > are subject to change when we discover new requirements for the pool. > > Current exported interfaces include: > > page_pool_init: pool init > page_pool_destroy: pool destruction > page_pool_get: get a page from pool > page_pool_put: put page back to pool > is_in_pool: tell whether a page belongs to the pool > > Current implementation has following defects: > - Global locking > - No starve prevention mechanism / reservation logic > > Global locking tends to cause contention on the pool. No reservation > logic may cause vif to starve. A possible solution to these two > problems will be each vif maintains its local cache and claims a > portion of the pool. However the implementation will be tricky when > coming to pool management, so let's worry about that later. > > Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> > Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> > Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx> > --- 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. > +int page_pool_init() > +{ > + int cpus = 0; > + int i; > + > + cpus = num_online_cpus(); > + pool_size = cpus * ENTRIES_PER_CPU; > + > + pool = vzalloc(sizeof(struct page_pool_entry) * pool_size); > + > + if (!pool) > + return -ENOMEM; > + > + for (i = 0; i < pool_size - 1; i++) > + pool[i].u.fl = i+1; > + pool[pool_size-1].u.fl = INVALID_ENTRY; > + free_count = pool_size; > + free_head = 0; > + > + return 0; > +} > + num_online_cpus() disease once again. code depending on num_online_cpus() is always suspicious. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |