>>> On 29.09.15 at 11:11, <t...@xen.org> wrote: > With the flush taking longer than Xen can wait for, you'll need to > do something more complex, e.g.: > - keep a log of all relevant pending derefs, to be processed when the > flush completes; or > - have some other method of preventing changes of ownership/type on > the relevant pages. E.g. for CPU TLBs, we keep a per-page counter > (tlbflush-timestamp) that we can use to detect whether enough TLB > flushes have happened since the page was freed. > > The log is tricky - I'm not sure how toq make sure that it has bounded > size if a flush can take seconds. > > I'm not sure the counter works either -- when that detector triggers > we do a synchronous TLB-flush IPI to make the operation safe, and > that's exactly what we can't do here. > > Any other ideas floating around?
The variant of the log model might work if sufficient information is available in the interrupt handler (or associated tasklet) to identify a much smaller subset of pages to scan through. Since there is a 32-bit quantity written to a pre-determined location upon qi completion, I wonder whether that couldn't be used for that purpose - 32 bits disambiguate a page within 16Tb of RAM, so there wouldn't need to be too many hashed together in a single chain. Otoh of course we can't have 2^32 standalone list heads. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
