On Mon, Nov 14, 2005 at 02:34:46PM -0600, James Dickens wrote: | > paging candidate determination very costly). ZFS is very fast (being copy- | > on-write it does sequential I/Os whereas swapfs does random disk access), | > and it supports compression. ZFS is already slated to become the new | > replacement to swapfs in the near future. | | If this is the case, compressed cache may become a mute point since last i | heard zfs allowed compression of its data and it kept the data compressed as | well when it was cached.
Yes, that's correct, though in this case ZFS does not cache the data in the page cache but in its own cache (where mmap() cannot find it). When mmap() MAP_SHARED is in use ZFS is forced to use the page cache and cannot cache the data compressed since there is only one copy of the data in memory (Solaris provides no way to keep mmap()-shared mappings and a separate cache consistent). The current concept is to implement the new anon layer using "stacked vnodes" so the policy for caching swap data is completely left up to the filesystem -- e.g. if ZFS has cached copies of its compressed backing store files and the uncached copies are present in the process address space, that's fine; ZFS will implement its own algorithms (which are quite sophisticated) to decide when to recycle the compressed cache copy long after the uncompressed copies are destroyed by the paging system. -- Eric Lowe Solaris Kernel Development Austin, Texas Sun Microsystems. We make the net work. x64155/+1(512)401-1155 _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
