----- Original Message ----- > Hi, > > > On 05/06/15 15:49, Bob Peterson wrote: > > Hi, > > > > This patch allows the block allocation code to retain the buffers > > for the resource groups so they don't need to be re-read from buffer > > cache with every request. This is a performance improvement that's > > especially noticeable when resource groups are very large. For > > example, with 2GB resource groups and 4K blocks, there can be 33 > > blocks for every resource group. This patch allows those 33 buffers > > to be kept around and not read in and thrown away with every > > operation. The buffers are released when the resource group is > > either synced or invalidated. > The blocks should be cached between operations, so this should only be > resulting in a skip of the look up of the cached block, and no changes > to the actual I/O. Does that mean that grab_cache_page() is slow I > wonder? Or is this an issue of going around the retry loop due to lack > of memory at some stage? > > How does this interact with the rgrplvb support? I'd guess that with > that turned on, this is no longer an issue, because we'd only read in > the blocks for the rgrps that we are actually going to use? > > > > Steve.
Hi, If you compare the two vmstat outputs in the bugzilla #1154782, you'll see no significant difference in memory usage nor cpu usage. So I assume the page lookup is the "slow" part; not because it's such a slow thing but because it's done 33 times per read-reference-invalidate (33 pages to look up per rgrp). Regards, Bob Peterson Red Hat File Systems