From: Nikolay Borisov <nborisov@suse.com>
To: Josef Bacik <josef@toxicpanda.com>
Cc: kernel-team@fb.com, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 6/8] btrfs: rework wake_all_tickets
Date: Tue, 20 Aug 2019 10:51:07 +0300 [thread overview]
Message-ID: <95aa4f11-760b-f056-fe20-8bf8a3097cfd@suse.com> (raw)
In-Reply-To: <20190819150601.rj4k2li2f2bl35eo@MacBook-Pro-91.local>
On 19.08.19 г. 18:06 ч., Josef Bacik wrote:
> On Mon, Aug 19, 2019 at 05:49:45PM +0300, Nikolay Borisov wrote:
>>
>>
>> On 16.08.19 г. 17:19 ч., Josef Bacik wrote:
>>> Now that we no longer partially fill tickets we need to rework
>>> wake_all_tickets to call btrfs_try_to_wakeup_tickets() in order to see
>>> if any subsequent tickets are able to be satisfied. If our tickets_id
>>> changes we know something happened and we can keep flushing.
>>>
>>> Also if we find a ticket that is smaller than the first ticket in our
>>> queue then we want to retry the flushing loop again in case
>>> may_commit_transaction() decides we could satisfy the ticket by
>>> committing the transaction.
>>>
>>> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
>>> ---
>>> fs/btrfs/space-info.c | 34 +++++++++++++++++++++++++++-------
>>> 1 file changed, 27 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c
>>> index 8a1c7ada67cb..bd485be783b8 100644
>>> --- a/fs/btrfs/space-info.c
>>> +++ b/fs/btrfs/space-info.c
>>> @@ -676,19 +676,39 @@ static inline int need_do_async_reclaim(struct btrfs_fs_info *fs_info,
>>> !test_bit(BTRFS_FS_STATE_REMOUNTING, &fs_info->fs_state));
>>> }
>>>
>>> -static bool wake_all_tickets(struct list_head *head)
>>> +static bool wake_all_tickets(struct btrfs_fs_info *fs_info,
>>> + struct btrfs_space_info *space_info)
>>> {
>>> struct reserve_ticket *ticket;
>>> + u64 tickets_id = space_info->tickets_id;
>>> + u64 first_ticket_bytes = 0;
>>> +
>>> + while (!list_empty(&space_info->tickets) &&
>>> + tickets_id == space_info->tickets_id) {
>>> + ticket = list_first_entry(&space_info->tickets,
>>> + struct reserve_ticket, list);
>>> +
>>> + /*
>>> + * may_commit_transaction will avoid committing the transaction
>>> + * if it doesn't feel like the space reclaimed by the commit
>>> + * would result in the ticket succeeding. However if we have a
>>> + * smaller ticket in the queue it may be small enough to be
>>> + * satisified by committing the transaction, so if any
>>> + * subsequent ticket is smaller than the first ticket go ahead
>>> + * and send us back for another loop through the enospc flushing
>>> + * code.
>>> + */
>>> + if (first_ticket_bytes == 0)
>>> + first_ticket_bytes = ticket->bytes;
>>> + else if (first_ticket_bytes > ticket->bytes)
>>> + return true;
>>>
>>> - while (!list_empty(head)) {
>>> - ticket = list_first_entry(head, struct reserve_ticket, list);
>>> list_del_init(&ticket->list);
>>> ticket->error = -ENOSPC;
>>> wake_up(&ticket->wait);
>>> - if (ticket->bytes != ticket->orig_bytes)
>>> - return true;
>>> + btrfs_try_to_wakeup_tickets(fs_info, space_info);
>>
>> So the change in this logic is directly related to the implementation of
>> btrfs_try_to_wakeup_tickets. Because when we fail and remove a ticket in
>> this function we give a chance that the next ticket *could* be
>> satisfied. But how well does that work in practice, given you fail
>> normal prio tickets here, whereas btrfs_try_to_wakeup_tickets first
>> checks the prio ticket. So even if you are failing normal ticket but
>> there is one unsatifiable prio ticket that won't really change anything.
>
> In practice we don't get to this state with high priority tickets on the list.
> Anything that would be long-ish term on the priority list is evict, and we wait
> for iput()'s in the normal flushing code. At the point we hit wake_all_tickets
> we generally should only have tickets on the normal list.
Be that as it may, I think this assumption needs to be codified via an
assert or WARN_ON.
>
> I suppose we could possibly get into this situation, but again the high priority
> tickets are going to be evict, truncate block, and relocate, which all have
> significantly lower reservation amounts than things like create or unlink. If
> those things are unable to get reservations then we are truly out of space.
> Thanks,
>
> Josef
>
next prev parent reply other threads:[~2019-08-20 7:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-16 14:19 [PATCH 0/8][v2] Rework reserve ticket handling Josef Bacik
2019-08-16 14:19 ` [PATCH 1/8] btrfs: do not allow reservations if we have pending tickets Josef Bacik
2019-08-19 12:54 ` Nikolay Borisov
2019-08-19 12:57 ` Josef Bacik
2019-08-16 14:19 ` [PATCH 2/8] btrfs: roll tracepoint into btrfs_space_info_update helper Josef Bacik
2019-08-16 14:19 ` [PATCH 3/8] btrfs: add space reservation tracepoint for reserved bytes Josef Bacik
2019-08-16 14:19 ` [PATCH 4/8] btrfs: rework btrfs_space_info_add_old_bytes Josef Bacik
2019-08-16 14:19 ` [PATCH 5/8] btrfs: refactor the ticket wakeup code Josef Bacik
2019-08-19 13:58 ` Nikolay Borisov
2019-08-16 14:19 ` [PATCH 6/8] btrfs: rework wake_all_tickets Josef Bacik
2019-08-19 14:49 ` Nikolay Borisov
2019-08-19 15:06 ` Josef Bacik
2019-08-20 7:51 ` Nikolay Borisov [this message]
2019-08-16 14:19 ` [PATCH 7/8] btrfs: fix may_commit_transaction to deal with no partial filling Josef Bacik
2019-08-20 8:20 ` Nikolay Borisov
2019-08-16 14:19 ` [PATCH 8/8] btrfs: remove orig_bytes from reserve_ticket Josef Bacik
2019-08-20 8:28 ` Nikolay Borisov
2019-08-21 14:07 ` David Sterba
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=95aa4f11-760b-f056-fe20-8bf8a3097cfd@suse.com \
--to=nborisov@suse.com \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.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