[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |