[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 04/10] xen/blkfront: separate ring information to an new struct



> > > AFAICT you seem to have a list of persistent grants, indirect pages
> > > and a grant table callback for each ring, isn't this supposed to be
> > > shared between all rings?
> > >
> > > I don't think we should be going down that route, or else we can hoard
> > > a large amount of memory and grants.
> > 
> > It does remove the lock that would have to be accessed by each ring thread 
> > to
> > access those. Those values (grants) can be limited to be a smaller value 
> > such
> > that the overall number is the same as it was with the previous version. As 
> > in:
> > each ring has = MAX_GRANTS / nr_online_cpus().
> > >
> 
> We should definitely be concerned with the amount of memory consumed on the 
> backend for each plugged virtual disk. We have faced several problems in 
> XenServer around this area before; it drastically affects VBD scalability per 
> host.
> 
> This makes me think that all the persistent grants work was done as a 
> workaround while we were facing several performance problems around 
> concurrent grant un/mapping operations. Given all the recent submissions made 
> around this (grant ops) area, is this something we should perhaps revisit and 
> discuss whether we want to continue offering persistent grants as a feature?
> 

Certainly. Perhaps as a talking point at XenHackathon?

> Thanks,
> Felipe

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.