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. Do we really need code to shrink the lofi decompress cache at runtime?
