linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Nikolay Borisov <nborisov@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 00/14] Misc transaction cleanups
Date: Mon, 12 Feb 2018 18:58:19 +0100	[thread overview]
Message-ID: <20180212175819.GN3003@twin.jikos.cz> (raw)
In-Reply-To: <1518018950-31456-1-git-send-email-nborisov@suse.com>

On Wed, Feb 07, 2018 at 05:55:36PM +0200, Nikolay Borisov wrote:
> Here are a bunch of transaction-related cleanups all of them present no 
> functional changes. The first 2 patches could be more interesting - the first
> one moves trans_release_metadata to transaction.c and makes it static and the 
> second one opencodes btrfs_write_and_wait_marked_extents in its sole caller
> to make the chall chain shorter. The rest of the patches just kill the 
> extraneous fs_info argument since they also take either a btrfs_trans_handle or
> btrfs_transaction pointer which already contain fs_info. 
> 
> The modified functions are all called from btrfs_commit_transaction. With this
> series applied the only function which remain that still take fs_info and 
> some type of transaction reference are: 
> 
> btrfs_finish_extent_commit
> btrfs_qgroup_account_extents
> btrfs_run_delayed_refs
> 
> 
> The reason I haven't touched them is that David expressed some reservation 
> about mass cleaning of functions which are more or less public interface. And 
> the above 3 are such functions. David if you don't objec to converting those 3
> I will keep them in mind when doing further cleanups in the transaction area. 

I think all 3 functions don't need the explicit fs_info parameter, the
main object for the functions is the transaction. I don't have a good
example for the API function that should keep both parameters, nothing
in transaction.h and nothing after a few quick greps. For functions like
add_delayed_ref_head, removing the fs_info would be a welcome change as
the number of parameters is high already (more than 10).

The patchset has been added to misc-next, briefly checking the effects
on stack consumption, there are several -8 deltas. Which is good.

      parent reply	other threads:[~2018-02-12 18:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-07 15:55 [PATCH 00/14] Misc transaction cleanups Nikolay Borisov
2018-02-07 15:55 ` [PATCH 01/14] btrfs: Make btrfs_trans_release_metadata private to transaction.c Nikolay Borisov
2018-02-07 15:55 ` [PATCH 02/14] btrfs: Open code btrfs_write_and_wait_marked_extents Nikolay Borisov
2018-02-07 15:55 ` [PATCH 03/14] btrfs: Remove fs_info argument from btrfs_trans_release_metadata Nikolay Borisov
2018-02-07 15:55 ` [PATCH 04/14] btrfs: Remove fs_info argument from btrfs_create_pending_block_groups Nikolay Borisov
2018-02-07 15:55 ` [PATCH 05/14] btrfs: Don't pass fs_info arg to btrfs_start_dirty_block_groups Nikolay Borisov
2018-02-07 15:55 ` [PATCH 06/14] btrfs: Don't pass fs_info to __btrfs_run_delayed_items Nikolay Borisov
2018-02-07 15:55 ` [PATCH 07/14] btrfs: Don't pass fs_info to btrfs_run_delayed_items/_nr Nikolay Borisov
2018-02-07 15:55 ` [PATCH 08/14] btrfs: Don't pass fs_info to commit_fs_roots Nikolay Borisov
2018-02-07 15:55 ` [PATCH 09/14] btrfs: Don't pass fs_info to commit_cowonly_roots Nikolay Borisov
2018-02-07 15:55 ` [PATCH 10/14] btrfs: Remove root argument of cleanup_transaction Nikolay Borisov
2018-02-07 15:55 ` [PATCH 11/14] btrfs: Remove fs_info argument from switch_commit_roots Nikolay Borisov
2018-02-07 15:55 ` [PATCH 12/14] btrfs: Remove fs_info argument from create_pending_snapshots/create_pending_snapshot Nikolay Borisov
2018-02-07 15:55 ` [PATCH 13/14] btrfs: Remove fs_info argument from btrfs_update_commit_device_bytes_used Nikolay Borisov
2018-02-07 15:55 ` [PATCH 14/14] btrfs: Remove fs_info argument of btrfs_write_and_wait_transaction Nikolay Borisov
2018-02-12 17:58 ` David Sterba [this message]

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=20180212175819.GN3003@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.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).