linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitrii Tcvetkov <demfloro@demfloro.ru>
To: Timofey Titovets <nefelim4ag@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2] Btrfs: enchanse raid1/10 balance heuristic
Date: Sat, 30 Dec 2017 11:14:04 +0300	[thread overview]
Message-ID: <20171230111404.4d424d95@xps.localdomain> (raw)
In-Reply-To: <CAGqmi74eMoBDGRJsZ6sSc3k5VrQvfK+WREvyxJxe9QM12FEH7w@mail.gmail.com>

On Sat, 30 Dec 2017 03:15:20 +0300
Timofey Titovets <nefelim4ag@gmail.com> wrote:

> 2017-12-29 22:14 GMT+03:00 Dmitrii Tcvetkov <demfloro@demfloro.ru>:
> > On Fri, 29 Dec 2017 21:44:19 +0300
> > Dmitrii Tcvetkov <demfloro@demfloro.ru> wrote:  
> >> > +/**
> >> > + * guess_optimal - return guessed optimal mirror
> >> > + *
> >> > + * Optimal expected to be pid % num_stripes
> >> > + *
> >> > + * That's generaly ok for spread load
> >> > + * Add some balancer based on queue leght to device
> >> > + *
> >> > + * Basic ideas:
> >> > + *  - Sequential read generate low amount of request
> >> > + *    so if load of drives are equal, use pid % num_stripes
> >> > balancing
> >> > + *  - For mixed rotate/non-rotate mirrors, pick non-rotate as
> >> > optimal
> >> > + *    and repick if other dev have "significant" less queue
> >> > lenght
> >> > + *  - Repick optimal if queue leght of other mirror are less
> >> > + */
> >> > +static int guess_optimal(struct map_lookup *map, int optimal)
> >> > +{
> >> > +   int i;
> >> > +   int round_down = 8;
> >> > +   int num = map->num_stripes;  
> >>
> >> num has to be initialized from map->sub_stripes if we're reading
> >> RAID10, otherwise there will be NULL pointer dereference
> >>  
> >
> > Check can be like:
> > if (map->type & BTRFS_BLOCK_GROUP_RAID10)
> >         num = map->sub_stripes;
> >  
> >>@@ -5804,10 +5914,12 @@ static int __btrfs_map_block(struct
> >>btrfs_fs_info *fs_info,
> >>                       stripe_index += mirror_num - 1;
> >>               else {
> >>                       int old_stripe_index = stripe_index;
> >>+                      optimal = guess_optimal(map,
> >>+                                      current->pid %
> >>map->num_stripes);
> >>                       stripe_index = find_live_mirror(fs_info, map,
> >>                                             stripe_index,
> >>                                             map->sub_stripes,
> >> stripe_index +
> >>-                                            current->pid %
> >>map->sub_stripes,
> >>+                                            optimal,
> >>                                             dev_replace_is_ongoing);
> >>                       mirror_num = stripe_index - old_stripe_index
> >> + 1; }
> >>--
> >>2.15.1  
> >
> > Also here calculation should be with map->sub_stripes too.
> > --
> > 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  
> 
> Why you think we need such check?
> I.e. guess_optimal always called for find_live_mirror()
> Both in same context, like that:
> 
> if (map->type & BTRFS_BLOCK_GROUP_RAID10) {
>   u32 factor = map->num_stripes / map->sub_stripes;
> 
>   stripe_nr = div_u64_rem(stripe_nr, factor, &stripe_index);
>   stripe_index *= map->sub_stripes;
> 
>   if (need_full_stripe(op))
>     num_stripes = map->sub_stripes;
>   else if (mirror_num)
>     stripe_index += mirror_num - 1;
>   else {
>     int old_stripe_index = stripe_index;
>     stripe_index = find_live_mirror(fs_info, map,
>       stripe_index,
>       map->sub_stripes, stripe_index +
>       current->pid % map->sub_stripes,
>       dev_replace_is_ongoing);
>     mirror_num = stripe_index - old_stripe_index + 1;
> }
> 
> That useless to check that internally

My bad, so only need to call 
guess_optimal(map, current->pid % map->sub_stripes)
in RAID10 branch.

  reply	other threads:[~2017-12-30  8:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-29  2:09 [PATCH v2] Btrfs: enchanse raid1/10 balance heuristic Timofey Titovets
2017-12-29 18:44 ` Dmitrii Tcvetkov
2017-12-29 19:14   ` Dmitrii Tcvetkov
2017-12-30  0:15     ` Timofey Titovets
2017-12-30  8:14       ` Dmitrii Tcvetkov [this message]
2017-12-30  9:47         ` Timofey Titovets

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=20171230111404.4d424d95@xps.localdomain \
    --to=demfloro@demfloro.ru \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nefelim4ag@gmail.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).