> > > 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@lists.xen.org http://lists.xen.org/xen-devel
