From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [GFS2 PATCH] GFS2: Don't brelse rgrp buffer_heads every allocation
Date: Tue, 16 Jun 2015 11:19:51 +0100 [thread overview]
Message-ID: <557FF847.6020605@redhat.com> (raw)
In-Reply-To: <1009689538.16731597.1434379434469.JavaMail.zimbra@redhat.com>
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.
next prev parent reply other threads:[~2015-06-16 10:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1673564717.11791069.1433515261791.JavaMail.zimbra@redhat.com>
2015-06-05 14:49 ` [Cluster-devel] [GFS2 PATCH] GFS2: Don't brelse rgrp buffer_heads every allocation Bob Peterson
2015-06-08 12:18 ` Steven Whitehouse
2015-06-09 14:45 ` Bob Peterson
2015-06-10 10:30 ` Steven Whitehouse
2015-06-12 19:50 ` Bob Peterson
2015-06-15 11:18 ` Steven Whitehouse
2015-06-15 13:56 ` Bob Peterson
2015-06-15 14:26 ` Steven Whitehouse
2015-06-15 14:43 ` Bob Peterson
2015-06-16 10:19 ` Steven Whitehouse [this message]
2015-06-16 13:54 ` Bob Peterson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=557FF847.6020605@redhat.com \
--to=swhiteho@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).