2009/3/11 Dina <dina.nimeh at sun.com>: > > > Juergen Keil wrote: >> >> 2009/3/10 Dina <dina.nimeh at sun.com>: >>> >>> usr/src/uts/common/io/lofi.c >> >> ... >>> >>> Questions: >>> >>> line 863, 865: lofi_max_comp_cache is tunable? ?What happens when it >>> ? ? ? switches between non-0 and 0 and back again? ?Is it possible >>> ? ? ? for cached segments to get orphaned, or get out of sync? >>> ? ? ? (Low likelihood...) >>> >>> ? ? ? Probably check for lsp->ls_comp_cache NULL-ness and take a >>> ? ? ? moment to dump out the cache if any. >>> >>> ? ? ? What if someone like me tunes lofi_max_comp_cache to 10240? >>> ? ? ? Should there be a max lofi_max_comp_cache? >> >> The lofi_max_comp_cache tunable was intended to compare opensolaris >> installation performance with and without the cache, and to compare >> performance when caching 1, 2, or more segments. >> >> It isn't intended to be a tunable that is officially documented. >> >> When you set it to some large value (10240), you'll be able to shoot >> yourself into the foot - the kernel might run out of kernel heap. >> >> >> Changing the tunable at runtime shouldn't break anything or leak memory. >> At this time you can increase the value at runtime, and the code should >> "do the right thing". ?Decreasing / changing from non-0 to 0 doesn't >> return >> cache kmem to the system immediately - it does release the memory when >> you unmap the file. > > This is the paragraph I wanted to focus on. ?If you have it set to 1 > at start, then during runtime you set it to 0. ?Now you have no caching. > The cache memory isn't returned immediately, yes. ?It sits there. > > <insert unknown period of time with unknown events w/r/t cached segment> > > Now you turn it back on by setting the value back to 1. ?The segment > that is already cached is still sitting there. ?What happens to it?
It will be reused, in case the next lofi read will result in a cache hit. Since compressed lofi only works in read/only mode, the cached uncompressed data is still valid. # lofiadm -a `pwd`/solaris.zlib /dev/lofi/5 # dd if=/dev/zero of=/dev/rlofi/5 count=2 write: Read-only file system 1+0 records in 1+0 records out Hmm, but why does the following work using the lofi block device? Seems to be another bug... I'd expect that this get s a EROFS error, too. # dd if=/dev/zero of=/dev/lofi/5 count=2 2+0 records in 2+0 records out > It releases the memory at unmap time, is unmapping the file a guaranteed > event at this point? ?If not, then does this lead to a stale segment in > the cache? No, patching / changing the lofi_max_comp_cache variable doesn't result in unmapping the file (that is calling lofi_free_handle(()). You would have to use lofiadm -d and close all references to the /dev/lofi/N file to get the cache memory released. Hmm, you could construct a case with attaching a compressed lofi file, and write to the underlying vnode. >> Do we really need code to shrink the lofi decompress cache at runtime? > > I think I understand that 1 cached segment gives a nice boost. ?And that > the improvement is probably not linear. At some point it doesn't matter > if you have 5 or 10 for your max cache size, the incremental performance > improvement may no longer be noticeable. > > That's why I asked what would happen if I set it 10240. ?Would it really > grow to 10240, or would it cut me off somewhere and not grow anymore, to > prevent running out of heap? It would grow to 10240 cached segments.
