David Chinner wrote: > You mean xfs_buf.c. > Yes, sorry.
> And yes, we delay unmapping pages until we have a batch of them > to unmap. vmap and vunmap do not scale, so this is batching helps > alleviate some of the worst of the problems. > How much performance does it cost? What kind of workloads would it show up under? > Realistically, if this delayed release of vmaps is a problem for > Xen, then I think that some generic VM solution is needed to this > problem as vmap() is likely to become more common in future (think > large blocks in filesystems). Nick - any comments? > Well, the only real problem is that the pages are returned to the free pool and reallocated while still being part of a mapping. If the pages are still owned by the filesystem/pagecache, then there's no problem. What's the lifetime of things being vmapped/unmapped in xfs? Are they necessarily being freed when they're unmapped, or could unmapping of freed memory be more immediate than other memory? Maybe it just needs a notifier chain or something. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/