From: Yien Zheng <esprout@gmail.com>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: linux-btrfs@vger.kernel.org, Josef Bacik <jbacik@redhat.com>
Subject: Re: [PATCH] Btrfs: take block group fragmentation into account for allocation
Date: Sun, 8 Mar 2009 20:03:36 -0600 [thread overview]
Message-ID: <2c259a8f0903081903w7cebb98excfbf9a4ec5c147d8@mail.gmail.com> (raw)
In-Reply-To: <20090308163707.GC11787@kernel.dk>
Thanks Jens! My research had indicated something about 64-bit
division and using do_div, but you cleared it up for me.
The fragmentation_percent function ultimately does another divide to
get the percentage, so here's what I did to get the function to work:
static int fragmentation_percent(struct btrfs_block_group_cache *block_=
group)
{
u64 max_fragments;
u64 fragments_ratio;
max_fragments =3D block_group->key.offset -
btrfs_block_group_used(&block_group->item);
do_div(max_fragments, block_group->fragment_size);
fragments_ratio =3D block_group->fragments;
do_div(fragments_ratio, max_fragments);
return (fragments_ratio * 100);
}
On Sun, Mar 8, 2009 at 10:37 AM, Jens Axboe <jens.axboe@oracle.com> wro=
te:
> On Sun, Mar 08 2009, Yien Zheng wrote:
>> I tried applying this patch, but the fragmentation_percent function =
is
>> giving me:
>>
>> WARNING: "__udivdi3"
>> [/home/partition6/yien/git/linux-git/fs/btrfs/btrfs.ko] undefined!
>>
>> when I compile, and the module fails to load, even though the build
>> completes. =A0I've traced it to the calculation of max_fragments:
>>
>> max_fragments =3D (block_group->key.offset -
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 btrfs_block_group_used(&block_group->ite=
m)) /
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 block_group->fragment_size;
>>
>> It seems that accessing block_group in here is causing a reference t=
o
>> __udivdi3 somehow. =A0Any idea what's going on here?
>
> You can't to 64-bit divides on 32-bit archs. Make that
>
> max_fragments =3D block_group->key.offset - btrfs_block_group_used(&b=
lock_group->item);
> do_div(max_fragments, block_group->fragment_size);
>
> and it should work.
>
> --
> Jens Axboe
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-03-09 2:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-08 14:42 [PATCH] Btrfs: take block group fragmentation into account for allocation Yien Zheng
2009-03-08 16:37 ` Jens Axboe
2009-03-09 2:03 ` Yien Zheng [this message]
2009-03-09 13:56 ` Simon Holm Thøgersen
2009-03-09 15:21 ` Oliver Mattos
2009-03-09 15:24 ` Josef Bacik
2009-03-09 17:29 ` jim owens
-- strict thread matches above, loose matches on Subject: below --
2009-03-06 19:30 Josef Bacik
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=2c259a8f0903081903w7cebb98excfbf9a4ec5c147d8@mail.gmail.com \
--to=esprout@gmail.com \
--cc=jbacik@redhat.com \
--cc=jens.axboe@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
/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