> > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
