From: David Sterba <dsterba@suse.cz>
To: Mark Harmstone <maharmstone@meta.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
"io-uring@vger.kernel.org" <io-uring@vger.kernel.org>
Subject: Re: [PATCH 5/5] btrfs: add io_uring command for encoded reads
Date: Mon, 21 Oct 2024 20:23:24 +0200 [thread overview]
Message-ID: <20241021182324.GA24631@suse.cz> (raw)
In-Reply-To: <f4f64bfe-c92b-4656-adec-d073b6286451@meta.com>
On Mon, Oct 21, 2024 at 05:05:20PM +0000, Mark Harmstone wrote:
> >> +static int btrfs_uring_encoded_read(struct io_uring_cmd *cmd,
> >> + unsigned int issue_flags)
> >> +{
> >> + size_t copy_end_kernel = offsetofend(struct btrfs_ioctl_encoded_io_args,
> >> + flags);
> >> + size_t copy_end;
> >> + struct btrfs_ioctl_encoded_io_args args = {0};
> > = { 0 }
> >> + int ret;
> >> + u64 disk_bytenr, disk_io_size;
> >> + struct file *file = cmd->file;
> >> + struct btrfs_inode *inode = BTRFS_I(file->f_inode);
> >> + struct btrfs_fs_info *fs_info = inode->root->fs_info;
> >> + struct extent_io_tree *io_tree = &inode->io_tree;
> >> + struct iovec iovstack[UIO_FASTIOV];
> >> + struct iovec *iov = iovstack;
> >> + struct iov_iter iter;
> >> + loff_t pos;
> >> + struct kiocb kiocb;
> >> + struct extent_state *cached_state = NULL;
> >> + u64 start, lockend;
> >
> > The stack consumption looks quite high.
>
> 696 bytes, compared to 672 in btrfs_ioctl_encoded_read.
> btrfs_ioctl_encoded write is pretty big too. Probably the easiest thing
> here would be to allocate btrfs_uring_priv early and pass that around, I
> think.
>
> Do you have a recommendation for what the maximum stack size of a
> function should be?
It depends from where the function is called. For ioctl callbacks, like
btrfs_ioctl_encoded_read it's the first function using kernel stack
leaving enough for any deep IO stacks (DM/NFS/iSCSI/...). If something
similar applies to the io_uring callbacks then it's probably fine.
Using a separate off-stack structure works but it's a penalty as it
needs the allcation. The io_uring is meant for high performance so if
the on-stack allocation is safe then keep it like that.
I've checked on a release config the stack consumption and the encoded
ioctl functions are not the worst:
tree-log.c:btrfs_sync_log 728 static
scrub.c:scrub_verify_one_metadata 552 dynamic,bounded
inode.c:print_data_reloc_error 544 dynamic,bounded
uuid-tree.c:btrfs_uuid_scan_kthread 520 static
tree-checker.c:check_root_item 504 static
file-item.c:btrfs_csum_one_bio 496 static
inode.c:btrfs_start_delalloc_roots 488 static
scrub.c:scrub_raid56_parity_stripe 464 dynamic,bounded
disk-io.c:write_dev_supers 464 static
ioctl.c:btrfs_ioctl_encoded_write 456 dynamic,bounded
ioctl.c:btrfs_ioctl_encoded_read 456 dynamic,bounded
next prev parent reply other threads:[~2024-10-21 18:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-14 17:18 [PATCH v3 0/5] btrfs: encoded reads via io_uring Mark Harmstone
2024-10-14 17:18 ` [PATCH 1/5] btrfs: remove pointless addition in btrfs_encoded_read Mark Harmstone
2024-10-14 17:18 ` [PATCH 2/5] btrfs: change btrfs_encoded_read_regular_fill_pages to take a callback Mark Harmstone
2024-10-15 15:23 ` David Sterba
2024-10-21 13:21 ` David Sterba
2024-10-14 17:18 ` [PATCH 3/5] btrfs: change btrfs_encoded_read so that reading of extent is done by caller Mark Harmstone
2024-10-14 17:18 ` [PATCH 4/5] btrfs: add nowait parameter to btrfs_encoded_read Mark Harmstone
2024-10-14 22:12 ` Jens Axboe
2024-10-15 8:48 ` Mark Harmstone
2024-10-14 17:18 ` [PATCH 5/5] btrfs: add io_uring command for encoded reads Mark Harmstone
2024-10-21 13:50 ` David Sterba
2024-10-21 16:15 ` Pavel Begunkov
2024-10-21 17:05 ` Mark Harmstone
2024-10-21 18:23 ` David Sterba [this message]
2024-10-22 9:12 ` Mark Harmstone
2024-10-14 17:44 ` [PATCH v3 0/5] btrfs: encoded reads via io_uring Boris Burkov
2024-10-15 8:50 ` Mark Harmstone
-- strict thread matches above, loose matches on Subject: below --
2024-10-22 14:50 [PATCH v4 0/5] btrfs: io_uring interface for encoded reads Mark Harmstone
2024-10-22 14:50 ` [PATCH 5/5] btrfs: add io_uring command " Mark Harmstone
2024-10-29 21:51 ` David Sterba
2024-10-30 0:59 ` Pavel Begunkov
2024-10-30 1:24 ` David Sterba
2024-10-30 2:32 ` Pavel Begunkov
2024-10-31 17:08 ` Mark Harmstone
2024-10-31 18:26 ` Pavel Begunkov
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=20241021182324.GA24631@suse.cz \
--to=dsterba@suse.cz \
--cc=io-uring@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=maharmstone@meta.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