sanjay nadkarni (Laptop) wrote: > 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. >
I approached this a code review. If there are use-cases that go along with this, I can look them to see if my comments make sense in that context. D. > > -Sanjay > >> >> D. >> >
