Dina wrote: > > > 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 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? This is not a normal use case. There are lots of kernel tunables which can get one into trouble if used improperly. If there's a memory leak or heap overflow as a result of this feature in any use case I would be concerned. > >> >> 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? I think what you are pointing out is that the tunable setting for 1 is specific for the liveCD. While your concern is valid, do have some specific use case in mind where this might be problematic.
-Sanjay > > D. >
