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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
