Re: [PATCH] fs/buffer.c: remove per-CPU buffer_head lookup cache

[Marcelo Tosatti]

On Mon, Jun 26, 2023 at 07:47:42PM +0100, Matthew Wilcox wrote:
> On Mon, Jun 26, 2023 at 03:04:53PM -0300, Marcelo Tosatti wrote:
> > Upon closer investigation, it was found that in current codebase, lookup_bh_lru
> > is slower than __find_get_block_slow:
> > 
> >  114 ns per __find_get_block
> >  68 ns per __find_get_block_slow
> > 
> > So remove the per-CPU buffer_head caching.
> 
> LOL.  That's amazing.  I can't even see why it's so expensive.  The
> local_irq_disable(), perhaps?  Your test case is the best possible
> one for lookup_bh_lru() where you're not even doing the copy.

Oops, that was due to incorrect buffer size being looked up versus
installed size. 

About 15ns is due to irq disablement.
6ns due to checking preempt is disabled (from __this_cpu_read).

So the actual numbers for the single block lookup are 
(searching for the same block number repeatedly):

42 ns per __find_get_block
68 ns per __find_get_block_slow

And increases linearly as the test increases the number of blocks which 
are searched for:

	say mod 3 is

	__find_get_block(blocknr=1)
	__find_get_block(blocknr=2)
	__find_get_block(blocknr=3)

41 ns per __find_get_block  mod=1
41 ns per __find_get_block  mod=2
42 ns per __find_get_block  mod=3
43 ns per __find_get_block  mod=4
45 ns per __find_get_block  mod=5
48 ns per __find_get_block  mod=6
48 ns per __find_get_block  mod=7
49 ns per __find_get_block  mod=8
51 ns per __find_get_block  mod=9
52 ns per __find_get_block  mod=10
54 ns per __find_get_block  mod=11
56 ns per __find_get_block  mod=12
58 ns per __find_get_block  mod=13
60 ns per __find_get_block  mod=14
61 ns per __find_get_block  mod=15
63 ns per __find_get_block  mod=16
138 ns per __find_get_block  mod=17
138 ns per __find_get_block  mod=18
138 ns per __find_get_block  mod=19		<-- results from first patch, when
						    lookup_bh_lru is a miss
70 ns per __find_get_block_slow mod=1
71 ns per __find_get_block_slow mod=2
71 ns per __find_get_block_slow mod=3
71 ns per __find_get_block_slow mod=4
71 ns per __find_get_block_slow mod=5
72 ns per __find_get_block_slow mod=6
71 ns per __find_get_block_slow mod=7
72 ns per __find_get_block_slow mod=8
71 ns per __find_get_block_slow mod=9
71 ns per __find_get_block_slow mod=10
71 ns per __find_get_block_slow mod=11
71 ns per __find_get_block_slow mod=12
71 ns per __find_get_block_slow mod=13
71 ns per __find_get_block_slow mod=14
71 ns per __find_get_block_slow mod=15
71 ns per __find_get_block_slow mod=16
71 ns per __find_get_block_slow mod=17
72 ns per __find_get_block_slow mod=18
72 ns per __find_get_block_slow mod=19

ls on home directory:
hits: 2 misses: 91

find on a linux-2.6 git tree:
hits: 25453 misses: 51084

make clean on a linux-2.6 git tree:
hits: 247615 misses: 32855

make on a linux-2.6 git tree:
hits: 1410414 misses: 166896

In more detail, where each bucket below indicates which index into
per-CPU buffer lookup_bh_lru was found:

hits idx1   idx2  ...                                                          idx16
hits 139506 24299 21597 7462 15790 19108 6477 1349 1237 938 845 636 637 523 431 454 misses: 65773

So i think it makes more sense to just disable the cache for isolated
CPUs.

> Reviewed-by: Matthew Wilcox (oracle) <willy@xxxxxxxxxxxxx>

Thanks.