From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Tue, 16 Jun 2015 11:19:51 +0100 Subject: [Cluster-devel] [GFS2 PATCH] GFS2: Don't brelse rgrp buffer_heads every allocation In-Reply-To: <1009689538.16731597.1434379434469.JavaMail.zimbra@redhat.com> References: <40631507.11797438.1433515756742.JavaMail.zimbra@redhat.com> <55758830.6080405@redhat.com> <1353222669.13489616.1433861153801.JavaMail.zimbra@redhat.com> <557811B0.2050406@redhat.com> <2055885404.16127476.1434138634146.JavaMail.zimbra@redhat.com> <557EB48E.4020104@redhat.com> <1486199193.16648722.1434376611350.JavaMail.zimbra@redhat.com> <557EE0AE.1070807@redhat.com> <1009689538.16731597.1434379434469.JavaMail.zimbra@redhat.com> Message-ID: <557FF847.6020605@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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.