[Cluster-devel] [GFS2 PATCH] GFS2: Don't brelse rgrp buffer_heads every allocation

Steven Whitehouse swhiteho at redhat.com
Tue Jun 16 10:19:51 UTC 2015


Hi,

On 15/06/15 15:43, Bob Peterson wrote:
> ----- Original Message -----
>> I'm assuming that these figures are bandwidth rather than times, since
>> that appears to show that the patch makes quite a large difference.
>> However the reclen is rather small. In the 32 bytes case, thats 128
>> writes for each new block thats being allocated, unless of course that
>> is 32k?
>>
>> Steve.
> Hi,
>
> To do this test, I'm executing this command:
> numactl --cpunodebind=0 --membind=0 /home/bob/iozone/iozone3_429/src/current/iozone -az -f /mnt/gfs2/iozone-gfs2 -n 2048m -g 2048m -y 32k -q 1m -e -i 0 -+n &> /home/bob/iozone.out
>
> According to iozone -h, specifying -y this way is 32K, not 32 bytes.
> The -q is maximum write size, in KB, so -q 1m is 1MB writes.
> The -g is maximum file size, in KB, so -g 2048 is a 2MB file.
>
> So the test varies the writes from 32K to 1MB, adjusting the number
> of writes to get the file to 2MB.
>
> Regards,
>
> Bob Peterson
> Red Hat File Systems

Ok, that makes sense to me. I guess that there is not a lot of searching 
for the rgrps going on, which is why we are not seeing a big gain in the 
rgrplvb case. If the fs was nearly full perhaps we'd see more of a 
difference in that case.

Either way, provided the rgrplvb code can continue to work, that is 
really the important thing, so I think we should be ok with this. I'd 
still very much like to see what can be done to reduce the page look up 
cost more directly though, since that seems to be the real issue here,

Steve.




More information about the Cluster-devel mailing list