On Thu, 12 Mar 2009, Juergen Keil wrote: >> lofi.c: line 907: It seems like the lc_data field is always >> going to be of the lsp->ls_uncomp_seg_sz size. If the lofi_max_comp_cache is >> "1" (like it will be by default), we're >> going to be continually doing kmem_alloc/kmem_free of the same >> size. It seems to me that this would be perfect case for creating a >> kmem_cache instead so you hit that instead of >> going to the memory allocator every time. > > There is no invariant constructed object state that could be > preserved by using kmem_cache. And the allocations / frees > shouldn't happen that frequently (once per lofi compressed read > when the cache can't be used). I doubt that using > kmem_cache will result in any significant performance increase.
Yeah, an alloc/free is going to happen for every compressed segment (atleast in the case of the LiveCD). Considering that solaris.zlib is ~2.2Gb uncompressed, using the default segment size of 128k this is ~17600 segments. So, we're going to do that many alloc/frees. However, if we replace this with a kmem_cache then a single alloc/free (in the default case) happens and all subsequent requests go to the cache (even though there isn't any invariant state we're preserving). If you think this is okay to defer in the interest of getting the code into snv_111, I'm fine with that too. Alok
