On Thu, 10 Jul 2014 08:51:17 +0200 Sebastien Buisson <sebastien.buisson@xxxxxxxx> wrote: > Allow increasing the buffer-head per-CPU LRU size to allow efficient > filesystem operations that access many blocks for each transaction. > For example, creating a file in a large ext4 directory with quota > enabled will accesses multiple buffer heads and will overflow the LRU > at the default 8-block LRU size: > > * parent directory inode table block (ctime, nlinks for subdirs) > * new inode bitmap > * inode table block > * 2 quota blocks > * directory leaf block (not reused, but pollutes one cache entry) > * 2 levels htree blocks (only one is reused, other pollutes cache) > * 2 levels indirect/index blocks (only one is reused) > > The buffer-head per-CPU LRU size can be changed at config time, and its > default value is raised to 16. The patch is a performance optimisation but the changelog omits all mention of the most important part: the magnitude of the performance improvement. > --- a/fs/Kconfig > +++ b/fs/Kconfig > @@ -268,4 +268,18 @@ endif # NETWORK_FILESYSTEMS > source "fs/nls/Kconfig" > source "fs/dlm/Kconfig" > > +config BH_LARGE_LRU > + def_bool y > + depends on (EXT4_FS && QUOTA) > + > +config BH_LRU_SIZE > + int > + range 8 64 > + default "16" if BH_LARGE_LRU > + default "8" if !BH_LARGE_LRU > + help > + This sets the per-CPU LRU size for buffer heads in memory. > + More complex filesystems may be modifying multiple blocks > + within a single transaction, so keeping the buffer heads in > + CPU-local cache speeds up modifications significantly. This hardwires 16 if ext4"a and 8 otherwise. There's no way for anyone to alter this decision if they think it will be helpful (or harmful) in their setup. > endmenu > diff --git a/fs/buffer.c b/fs/buffer.c > index 6024877..b83fa63 100644 > --- a/fs/buffer.c > +++ b/fs/buffer.c > @@ -1255,8 +1255,7 @@ static struct buffer_head *__bread_slow(struct > buffer_head *bh) Your email client is wordwrapping the patches btw. And it replaces tabs with spaces. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
