From: Gao Xiang <gaoxiang25@huawei.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Chao Yu <yuchao0@huawei.com>,
Dan Carpenter <dan.carpenter@oracle.com>,
Joe Perches <joe@perches.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
<devel@driverdev.osuosl.org>, LKML <linux-kernel@vger.kernel.org>,
<linux-erofs@lists.ozlabs.org>, Chao Yu <chao@kernel.org>,
Miao Xie <miaoxie@huawei.com>, <weidu.du@huawei.com>,
"Fang Wei" <fangwei1@huawei.com>
Subject: Re: [PATCH v3 7/7] erofs: redundant assignment in __erofs_get_meta_page()
Date: Sat, 31 Aug 2019 00:48:27 +0800 [thread overview]
Message-ID: <20190830164827.GA107220@architecture4> (raw)
In-Reply-To: <20190830162812.GA10694@infradead.org>
Hi Christoph,
On Fri, Aug 30, 2019 at 09:28:12AM -0700, Christoph Hellwig wrote:
> > - err = bio_add_page(bio, page, PAGE_SIZE, 0);
> > - if (err != PAGE_SIZE) {
> > + if (bio_add_page(bio, page, PAGE_SIZE, 0) != PAGE_SIZE) {
> > err = -EFAULT;
> > goto err_out;
> > }
>
> This patch looks like an improvement. But looking at that whole
> area just makes me cringe.
OK, I agree with you, I will improve it or just kill them all with
new iomap approach after it supports tail-end packing inline.
>
> Why is there __erofs_get_meta_page with the two weird booleans instead
> of a single erofs_get_meta_page that gets and gfp_t for additional
> flags and an unsigned int for additional bio op flags.
I agree with you. Thanks for your suggestion.
>
> Why do need ioprio support to start with? Seeing that in a new
> fs look kinda odd. Do you have benchmarks that show the difference?
I don't have some benchmark for all of these, can I just set
REQ_PRIO for all metadata? is that reasonable?
Could you kindly give some suggestion on this?
>
> That function then calls erofs_grab_bio, which tries to handle a
> bio_alloc failure, except that the function will not actually fail
> due the mempool backing it. It also seems like and awfully
> huge function to inline.
OK, I will simplify it. Thanks for your suggestion.
>
> Why is there __submit_bio which really just obsfucates what is
> going on? Also why is __submit_bio using bio_set_op_attrs instead
> of opencode it as the comment right next to it asks you to?
Originally, mainly due to backport consideration since some
of our smartphones use 3.x kernel as well...
>
> Also I really don't understand why you can't just use read_cache_page
> or even read_cache_page_gfp instead of __erofs_get_meta_page.
> That function is a whole lot of duplication of functionality shared
> by a lot of other file systems.
OK, I have to admit, that code was originally just copied from f2fs
with some modification (maybe it's not a good example for us).
Thanks,
Gao Xiang
WARNING: multiple messages have this Message-ID (diff)
From: Gao Xiang <gaoxiang25@huawei.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: devel@driverdev.osuosl.org, Chao Yu <chao@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Miao Xie <miaoxie@huawei.com>, Chao Yu <yuchao0@huawei.com>,
LKML <linux-kernel@vger.kernel.org>,
weidu.du@huawei.com, Fang Wei <fangwei1@huawei.com>,
Joe Perches <joe@perches.com>,
linux-erofs@lists.ozlabs.org,
Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [PATCH v3 7/7] erofs: redundant assignment in __erofs_get_meta_page()
Date: Sat, 31 Aug 2019 00:48:27 +0800 [thread overview]
Message-ID: <20190830164827.GA107220@architecture4> (raw)
In-Reply-To: <20190830162812.GA10694@infradead.org>
Hi Christoph,
On Fri, Aug 30, 2019 at 09:28:12AM -0700, Christoph Hellwig wrote:
> > - err = bio_add_page(bio, page, PAGE_SIZE, 0);
> > - if (err != PAGE_SIZE) {
> > + if (bio_add_page(bio, page, PAGE_SIZE, 0) != PAGE_SIZE) {
> > err = -EFAULT;
> > goto err_out;
> > }
>
> This patch looks like an improvement. But looking at that whole
> area just makes me cringe.
OK, I agree with you, I will improve it or just kill them all with
new iomap approach after it supports tail-end packing inline.
>
> Why is there __erofs_get_meta_page with the two weird booleans instead
> of a single erofs_get_meta_page that gets and gfp_t for additional
> flags and an unsigned int for additional bio op flags.
I agree with you. Thanks for your suggestion.
>
> Why do need ioprio support to start with? Seeing that in a new
> fs look kinda odd. Do you have benchmarks that show the difference?
I don't have some benchmark for all of these, can I just set
REQ_PRIO for all metadata? is that reasonable?
Could you kindly give some suggestion on this?
>
> That function then calls erofs_grab_bio, which tries to handle a
> bio_alloc failure, except that the function will not actually fail
> due the mempool backing it. It also seems like and awfully
> huge function to inline.
OK, I will simplify it. Thanks for your suggestion.
>
> Why is there __submit_bio which really just obsfucates what is
> going on? Also why is __submit_bio using bio_set_op_attrs instead
> of opencode it as the comment right next to it asks you to?
Originally, mainly due to backport consideration since some
of our smartphones use 3.x kernel as well...
>
> Also I really don't understand why you can't just use read_cache_page
> or even read_cache_page_gfp instead of __erofs_get_meta_page.
> That function is a whole lot of duplication of functionality shared
> by a lot of other file systems.
OK, I have to admit, that code was originally just copied from f2fs
with some modification (maybe it's not a good example for us).
Thanks,
Gao Xiang
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
WARNING: multiple messages have this Message-ID (diff)
From: Gao Xiang <gaoxiang25@huawei.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: devel@driverdev.osuosl.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Miao Xie <miaoxie@huawei.com>,
LKML <linux-kernel@vger.kernel.org>,
weidu.du@huawei.com, Joe Perches <joe@perches.com>,
linux-erofs@lists.ozlabs.org,
Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [PATCH v3 7/7] erofs: redundant assignment in __erofs_get_meta_page()
Date: Sat, 31 Aug 2019 00:48:27 +0800 [thread overview]
Message-ID: <20190830164827.GA107220@architecture4> (raw)
In-Reply-To: <20190830162812.GA10694@infradead.org>
Hi Christoph,
On Fri, Aug 30, 2019 at 09:28:12AM -0700, Christoph Hellwig wrote:
> > - err = bio_add_page(bio, page, PAGE_SIZE, 0);
> > - if (err != PAGE_SIZE) {
> > + if (bio_add_page(bio, page, PAGE_SIZE, 0) != PAGE_SIZE) {
> > err = -EFAULT;
> > goto err_out;
> > }
>
> This patch looks like an improvement. But looking at that whole
> area just makes me cringe.
OK, I agree with you, I will improve it or just kill them all with
new iomap approach after it supports tail-end packing inline.
>
> Why is there __erofs_get_meta_page with the two weird booleans instead
> of a single erofs_get_meta_page that gets and gfp_t for additional
> flags and an unsigned int for additional bio op flags.
I agree with you. Thanks for your suggestion.
>
> Why do need ioprio support to start with? Seeing that in a new
> fs look kinda odd. Do you have benchmarks that show the difference?
I don't have some benchmark for all of these, can I just set
REQ_PRIO for all metadata? is that reasonable?
Could you kindly give some suggestion on this?
>
> That function then calls erofs_grab_bio, which tries to handle a
> bio_alloc failure, except that the function will not actually fail
> due the mempool backing it. It also seems like and awfully
> huge function to inline.
OK, I will simplify it. Thanks for your suggestion.
>
> Why is there __submit_bio which really just obsfucates what is
> going on? Also why is __submit_bio using bio_set_op_attrs instead
> of opencode it as the comment right next to it asks you to?
Originally, mainly due to backport consideration since some
of our smartphones use 3.x kernel as well...
>
> Also I really don't understand why you can't just use read_cache_page
> or even read_cache_page_gfp instead of __erofs_get_meta_page.
> That function is a whole lot of duplication of functionality shared
> by a lot of other file systems.
OK, I have to admit, that code was originally just copied from f2fs
with some modification (maybe it's not a good example for us).
Thanks,
Gao Xiang
next prev parent reply other threads:[~2019-08-30 16:49 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-30 3:00 [PATCH v2 1/7] erofs: on-disk format should have explicitly assigned numbers Gao Xiang
2019-08-30 3:00 ` Gao Xiang
2019-08-30 3:00 ` [PATCH v2 2/7] erofs: some marcos are much more readable as a function Gao Xiang
2019-08-30 3:00 ` Gao Xiang
2019-08-30 3:16 ` Joe Perches
2019-08-30 3:16 ` Joe Perches
2019-08-30 3:20 ` Gao Xiang
2019-08-30 3:20 ` Gao Xiang
2019-08-30 3:36 ` [PATCH v3 1/7] erofs: on-disk format should have explicitly assigned numbers Gao Xiang
2019-08-30 3:36 ` Gao Xiang
2019-08-30 3:36 ` [PATCH v3 2/7] erofs: some macros are much more readable as a function Gao Xiang
2019-08-30 3:36 ` Gao Xiang
2019-08-30 3:38 ` [PATCH v4 " Gao Xiang
2019-08-30 3:38 ` Gao Xiang
2019-08-30 6:11 ` [PATCH v3 " Chao Yu
2019-08-30 6:11 ` Chao Yu
2019-08-30 3:36 ` [PATCH v3 3/7] erofs: use a better form for complicated on-disk fields Gao Xiang
2019-08-30 3:36 ` Gao Xiang
2019-08-30 3:36 ` [PATCH v3 4/7] erofs: kill __packed for on-disk structures Gao Xiang
2019-08-30 3:36 ` Gao Xiang
2019-08-30 6:16 ` Chao Yu
2019-08-30 6:16 ` Chao Yu
2019-08-30 3:36 ` [PATCH v3 5/7] erofs: kill erofs_{init,exit}_inode_cache Gao Xiang
2019-08-30 3:36 ` Gao Xiang
2019-08-30 6:17 ` Chao Yu
2019-08-30 6:17 ` Chao Yu
2019-08-30 3:36 ` [PATCH v3 6/7] erofs: remove all likely/unlikely annotations Gao Xiang
2019-08-30 3:36 ` Gao Xiang
2019-08-30 6:25 ` Chao Yu
2019-08-30 6:25 ` Chao Yu
2019-08-30 6:31 ` Gao Xiang
2019-08-30 6:31 ` Gao Xiang
2019-08-30 6:43 ` Chao Yu
2019-08-30 6:43 ` Chao Yu
2019-08-30 11:55 ` Dan Carpenter
2019-08-30 11:55 ` Dan Carpenter
2019-08-30 11:30 ` Dan Carpenter
2019-08-30 11:30 ` Dan Carpenter
2019-08-30 12:06 ` Gao Xiang
2019-08-30 12:06 ` Gao Xiang via Linux-erofs
2019-08-30 15:46 ` Christoph Hellwig
2019-08-30 15:46 ` Christoph Hellwig
2019-08-30 15:46 ` Christoph Hellwig
2019-08-30 16:04 ` Gao Xiang
2019-08-30 16:04 ` Gao Xiang
2019-08-30 16:04 ` Gao Xiang
2019-08-31 10:57 ` Dan Carpenter
2019-08-31 10:57 ` Dan Carpenter
2019-08-31 10:57 ` Dan Carpenter
2019-08-30 3:36 ` [PATCH v3 7/7] erofs: redundant assignment in __erofs_get_meta_page() Gao Xiang
2019-08-30 3:36 ` Gao Xiang
2019-08-30 6:25 ` Chao Yu
2019-08-30 6:25 ` Chao Yu
2019-08-30 16:28 ` Christoph Hellwig
2019-08-30 16:28 ` Christoph Hellwig
2019-08-30 16:28 ` Christoph Hellwig
2019-08-30 16:48 ` Gao Xiang [this message]
2019-08-30 16:48 ` Gao Xiang
2019-08-30 16:48 ` Gao Xiang
2019-08-30 15:25 ` [PATCH v3 1/7] erofs: on-disk format should have explicitly assigned numbers Gao Xiang
2019-08-30 15:25 ` Gao Xiang
2019-08-30 15:25 ` Gao Xiang
2019-08-30 15:45 ` [PATCH v2 2/7] erofs: some marcos are much more readable as a function Christoph Hellwig
2019-08-30 15:45 ` Christoph Hellwig
2019-08-30 15:45 ` Christoph Hellwig
2019-08-30 15:52 ` Gao Xiang
2019-08-30 15:52 ` Gao Xiang
2019-08-30 15:52 ` Gao Xiang
2019-08-30 15:56 ` Gao Xiang
2019-08-30 15:56 ` Gao Xiang
2019-08-30 15:56 ` Gao Xiang
2019-08-30 3:00 ` [PATCH v2 3/7] erofs: use a better form for complicated on-disk fields Gao Xiang
2019-08-30 3:00 ` Gao Xiang
2019-08-30 3:29 ` Chao Yu
2019-08-30 3:29 ` Chao Yu
2019-08-30 3:00 ` [PATCH v2 4/7] erofs: kill __packed for on-disk structures Gao Xiang
2019-08-30 3:00 ` Gao Xiang
2019-08-30 3:00 ` [PATCH v2 5/7] erofs: kill erofs_{init,exit}_inode_cache Gao Xiang
2019-08-30 3:00 ` Gao Xiang
2019-08-30 3:00 ` [PATCH v2 6/7] erofs: remove all likely/unlikely annotations Gao Xiang
2019-08-30 3:00 ` Gao Xiang
2019-08-30 3:00 ` [PATCH v2 7/7] erofs: reduntant assignment in __erofs_get_meta_page() Gao Xiang
2019-08-30 3:00 ` Gao Xiang
2019-08-30 3:28 ` [PATCH v2 1/7] erofs: on-disk format should have explicitly assigned numbers Chao Yu
2019-08-30 3:28 ` Chao Yu
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=20190830164827.GA107220@architecture4 \
--to=gaoxiang25@huawei.com \
--cc=chao@kernel.org \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=fangwei1@huawei.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=joe@perches.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miaoxie@huawei.com \
--cc=weidu.du@huawei.com \
--cc=yuchao0@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.