| Message ID | 20230327174402.1655365-1-kent.overstreet@linux.dev (mailing list archive) |
|---|---|
| Headers | show |
| Series | bio iter improvements | expand |
On Mon, Mar 27, 2023 at 01:44:00PM -0400, Kent Overstreet wrote: > Small patch series cleaning up/standardizing bio_for_each_segment_all(), > which means we can use the same guts for bio_for_each_folio_all(), > considerably simplifying that code. > > The squashfs maintainer will want to look at and test those changes, > that code was doing some slightly tricky things. The rest was a pretty > mechanical conversion. Can you post a code size comparism for the before and after cases?
On Mon, Mar 27, 2023 at 7:02 PM Kent Overstreet <kent.overstreet@linux.dev> wrote: > > Small patch series cleaning up/standardizing bio_for_each_segment_all(), > which means we can use the same guts for bio_for_each_folio_all(), > considerably simplifying that code. > > The squashfs maintainer will want to look at and test those changes, > that code was doing some slightly tricky things. The rest was a pretty > mechanical conversion. An eyeball of the changes doesn't bring up anything obviously wrong. I'll apply and do some tests. Phillip BTW please CC me on the cover letter as well as patch [1/2]. > > Kent Overstreet (2): > block: Rework bio_for_each_segment_all() > block: Rework bio_for_each_folio_all() > > block/bio.c | 38 ++++++------ > block/blk-map.c | 38 ++++++------ > block/bounce.c | 12 ++-- > drivers/md/bcache/btree.c | 8 +-- > drivers/md/dm-crypt.c | 10 ++-- > drivers/md/raid1.c | 4 +- > fs/btrfs/disk-io.c | 10 ++-- > fs/btrfs/extent_io.c | 52 ++++++++-------- > fs/btrfs/inode.c | 8 +-- > fs/btrfs/raid56.c | 18 +++--- > fs/crypto/bio.c | 8 +-- > fs/erofs/zdata.c | 4 +- > fs/ext4/page-io.c | 8 +-- > fs/ext4/readpage.c | 4 +- > fs/f2fs/data.c | 20 +++---- > fs/gfs2/lops.c | 10 ++-- > fs/gfs2/meta_io.c | 8 +-- > fs/iomap/buffered-io.c | 14 +++-- > fs/mpage.c | 4 +- > fs/squashfs/block.c | 48 ++++++++------- > fs/squashfs/lz4_wrapper.c | 17 +++--- > fs/squashfs/lzo_wrapper.c | 17 +++--- > fs/verity/verify.c | 4 +- > include/linux/bio.h | 123 +++++++++++++++++++++----------------- > include/linux/bvec.h | 70 ++++++++++++++-------- > 25 files changed, 302 insertions(+), 255 deletions(-) > > -- > 2.39.2 >
On Tue, Mar 28, 2023 at 02:42:28PM +0100, Phillip Lougher wrote: > On Mon, Mar 27, 2023 at 7:02 PM Kent Overstreet > <kent.overstreet@linux.dev> wrote: > > > > Small patch series cleaning up/standardizing bio_for_each_segment_all(), > > which means we can use the same guts for bio_for_each_folio_all(), > > considerably simplifying that code. > > > > The squashfs maintainer will want to look at and test those changes, > > that code was doing some slightly tricky things. The rest was a pretty > > mechanical conversion. > > An eyeball of the changes doesn't bring up anything obviously wrong. > > I'll apply and do some tests. > > Phillip > > BTW please CC me on the cover letter as well as patch [1/2]. Will do. There were some squashfs files that got missed, there's a fixup patch you'll want in this branch: https://evilpiepirate.org/git/bcachefs.git/log/?h=bio_folio_iter
On Mon, Mar 27, 2023 at 03:14:05PM -0700, Christoph Hellwig wrote: > On Mon, Mar 27, 2023 at 01:44:00PM -0400, Kent Overstreet wrote: > > Small patch series cleaning up/standardizing bio_for_each_segment_all(), > > which means we can use the same guts for bio_for_each_folio_all(), > > considerably simplifying that code. > > > > The squashfs maintainer will want to look at and test those changes, > > that code was doing some slightly tricky things. The rest was a pretty > > mechanical conversion. > > Can you post a code size comparism for the before and after cases? 6.2: kent@moria:~/linux$ size ktest-out/kernel_build.x86_64/vmlinux text data bss dec hex filename 13234215 5355074 872448 19461737 128f669 ktest-out/kernel_build.x86_64/vmlinux With patches: kent@moria:~/linux$ size ktest-out/kernel_build.x86_64/vmlinux text data bss dec hex filename 13234215 5355578 872448 19462241 128f861 ktest-out/kernel_build.x86_64/vmlinux
On 28/03/2023 17:57, Kent Overstreet wrote: > On Tue, Mar 28, 2023 at 02:42:28PM +0100, Phillip Lougher wrote: >> On Mon, Mar 27, 2023 at 7:02 PM Kent Overstreet >> <kent.overstreet@linux.dev> wrote: >>> >>> Small patch series cleaning up/standardizing bio_for_each_segment_all(), >>> which means we can use the same guts for bio_for_each_folio_all(), >>> considerably simplifying that code. >>> >>> The squashfs maintainer will want to look at and test those changes, >>> that code was doing some slightly tricky things. The rest was a pretty >>> mechanical conversion. >> >> An eyeball of the changes doesn't bring up anything obviously wrong. >> >> I'll apply and do some tests. >> >> Phillip >> >> BTW please CC me on the cover letter as well as patch [1/2]. > > Will do. > > There were some squashfs files that got missed, there's a fixup patch > you'll want in this branch: > > https://evilpiepirate.org/git/bcachefs.git/log/?h=bio_folio_iter Patches applied, and I do see some issues in testing. I'll reply on patch [1/2] because that's where the code is. Phillip
On Tue, Mar 28, 2023 at 04:28:08PM -0400, Kent Overstreet wrote: > > Can you post a code size comparism for the before and after cases? > > 6.2: > kent@moria:~/linux$ size ktest-out/kernel_build.x86_64/vmlinux > text data bss dec hex filename > 13234215 5355074 872448 19461737 128f669 ktest-out/kernel_build.x86_64/vmlinux > > With patches: > kent@moria:~/linux$ size ktest-out/kernel_build.x86_64/vmlinux > text data bss dec hex filename > 13234215 5355578 872448 19462241 128f861 ktest-out/kernel_build.x86_64/vmlinux So we have a slightly larger binary size, and a slighly larger source code size. What is the overall benefit of this conversion?
On Mon, Apr 03, 2023 at 08:10:38AM -0700, Christoph Hellwig wrote: > On Tue, Mar 28, 2023 at 04:28:08PM -0400, Kent Overstreet wrote: > > > Can you post a code size comparism for the before and after cases? > > > > 6.2: > > kent@moria:~/linux$ size ktest-out/kernel_build.x86_64/vmlinux > > text data bss dec hex filename > > 13234215 5355074 872448 19461737 128f669 ktest-out/kernel_build.x86_64/vmlinux > > > > With patches: > > kent@moria:~/linux$ size ktest-out/kernel_build.x86_64/vmlinux > > text data bss dec hex filename > > 13234215 5355578 872448 19462241 128f861 ktest-out/kernel_build.x86_64/vmlinux > > So we have a slightly larger binary size, and a slighly larger source > code size. What is the overall benefit of this conversion? Data went up a bit because I added some asserts, yes. And it's also not uncommon for source code to grow a bit when you start focusing on readability instead of just playing code golf. And that was one of the main motivations - Matthew was complaining about the bio iter code being a pain in the ass when he did the bio folio iter code; additionally, I realized I could do a much cleaner and smaller version of bio_for_each_folio() with some refactoring of the existing code. But this was all right there in the original commit message. And to be honest Christoph, these kinds of drive by "let's focus on the easiest thing to measure" comments are what I expect from you at this point, but I don't find them to be super helpful. Reads like a typical MBA manager who just wants to focus on making their silly charts going up, instead of digging in and understanding what's going on. Was it your time in FinTech that you got that from...? If we want object size to go back down, we could - convert WARN_ONS() to BUG_ON()s (Linus won't like that) - drop the new assertions (_I_ wouldn't like that) - switch from inlines to out-of-line functions - this'll make text size go down vs. baseline, but if there's a performance impact Jens will care about that. Anyways, I've got a patch converting to out-of-line functions but I don't have as sensitive a performance testing setup as Jens does. If the patch is interesting to people - if Jens wants to perf test it or just take it - I'm happy to post it too.
On Mon, Apr 03, 2023 at 12:36:20PM -0400, Kent Overstreet wrote: > But this was all right there in the original commit message. And to be > honest Christoph, these kinds of drive by "let's focus on the easiest > thing to measure" comments are what I expect from you at this point, I'm really just curious what the motivation is. The code does not seem much cleaner to me as the user of the API, and it doesn't reduce code size. Maybe there is a good reason for it, but then it needs to be very clearly stated and you need to sell people on it. Starting to get personal instead tends to not help to convince your reviewers that it's really useful in general.
On Tue, Apr 04, 2023 at 08:20:01AM -0700, Christoph Hellwig wrote: > On Mon, Apr 03, 2023 at 12:36:20PM -0400, Kent Overstreet wrote: > > But this was all right there in the original commit message. And to be > > honest Christoph, these kinds of drive by "let's focus on the easiest > > thing to measure" comments are what I expect from you at this point, > > I'm really just curious what the motivation is. The code does not > seem much cleaner to me as the user of the API, and it doesn't reduce > code size. Maybe there is a good reason for it, but then it needs to > be very clearly stated and you need to sell people on it. Yeah, you're not trying to advance the discussion here, you're just restating your original position. I heard you, and I responded. > Starting to get personal instead tends to not help to convince your > reviewers that it's really useful in general. I know you and others like to talk a lot about what you want as maintainers and reviewers - but I find that the people who are the loudest and the most authoritarian in that respect tend not to be the people who drive discussions forward in productive ways.
On Tue, Apr 04, 2023 at 11:47:02AM -0400, Kent Overstreet wrote: > Yeah, you're not trying to advance the discussion here, you're just > restating your original position. I heard you, and I responded. Hi Kent, it might sound unusual to you, but yes, sometimes people ask questions to advance "the discussion" or to try to find out what someone else is actuall trying to do because it wasn't obvious. It then greatly helps if you treat it as just a question and not a personal attack.
>> Starting to get personal instead tends to not help to convince your >> reviewers that it's really useful in general. > > I know you and others like to talk a lot about what you want as > maintainers and reviewers - but I find that the people who are the > loudest and the most authoritarian in that respect tend not to be the > people who drive discussions forward in productive ways. One issue is certainly that nobody wants to engage with people that instantly try and make this personal, or just uncomfortable in general. Then it's better to focus on other things that are more rewarding and pleasant, nobody needs extra drama in their life. I sure as hell don't. And unfortunately I find that your postings most often degenerate to that. Which is a shame, because there's good stuff in a lot of these patches, but it's often not worth the time/energy investment because of it.
On Tue, Apr 04, 2023 at 10:01:58AM -0600, Jens Axboe wrote: > >> Starting to get personal instead tends to not help to convince your > >> reviewers that it's really useful in general. > > > > I know you and others like to talk a lot about what you want as > > maintainers and reviewers - but I find that the people who are the > > loudest and the most authoritarian in that respect tend not to be the > > people who drive discussions forward in productive ways. > > One issue is certainly that nobody wants to engage with people that > instantly try and make this personal, or just uncomfortable in general. Yeah, you like to respond to technical discussion with a *plonk*. *eyeroll* Christoph can handle himself, he doesn't need you defending him.
On Tue, Apr 04, 2023 at 08:59:51AM -0700, Christoph Hellwig wrote: > On Tue, Apr 04, 2023 at 11:47:02AM -0400, Kent Overstreet wrote: > > Yeah, you're not trying to advance the discussion here, you're just > > restating your original position. I heard you, and I responded. > > Hi Kent, > > it might sound unusual to you, but yes, sometimes people ask questions > to advance "the discussion" or to try to find out what someone else is > actuall trying to do because it wasn't obvious. It then greatly > helps if you treat it as just a question and not a personal attack. "Asking the question", when the question is basic and already been discussed/responded to, can also be a form of obtuse trolling.
On 4/4/23 10:06?AM, Kent Overstreet wrote: > On Tue, Apr 04, 2023 at 10:01:58AM -0600, Jens Axboe wrote: >>>> Starting to get personal instead tends to not help to convince your >>>> reviewers that it's really useful in general. >>> >>> I know you and others like to talk a lot about what you want as >>> maintainers and reviewers - but I find that the people who are the >>> loudest and the most authoritarian in that respect tend not to be the >>> people who drive discussions forward in productive ways. >> >> One issue is certainly that nobody wants to engage with people that >> instantly try and make this personal, or just uncomfortable in general. > > Yeah, you like to respond to technical discussion with a *plonk*. > > *eyeroll* > > Christoph can handle himself, he doesn't need you defending him. I'm not defending Christoph, I'm trying to help YOU understand why your patchsets always turn sour. And I'm trying to get this toxicity off the list, because it's frankly not productive at all and it's hurting the developer environment for everybody else. If everybody else seems like an asshole, maybe it's actually you? A little introspection would be prudent. If you can't change your tone, please just go somewhere else. I'm not interested.
On Tue, Apr 04, 2023 at 10:14:36AM -0600, Jens Axboe wrote: > On 4/4/23 10:06?AM, Kent Overstreet wrote: > > On Tue, Apr 04, 2023 at 10:01:58AM -0600, Jens Axboe wrote: > >>>> Starting to get personal instead tends to not help to convince your > >>>> reviewers that it's really useful in general. > >>> > >>> I know you and others like to talk a lot about what you want as > >>> maintainers and reviewers - but I find that the people who are the > >>> loudest and the most authoritarian in that respect tend not to be the > >>> people who drive discussions forward in productive ways. > >> > >> One issue is certainly that nobody wants to engage with people that > >> instantly try and make this personal, or just uncomfortable in general. > > > > Yeah, you like to respond to technical discussion with a *plonk*. > > > > *eyeroll* > > > > Christoph can handle himself, he doesn't need you defending him. > > I'm not defending Christoph, I'm trying to help YOU understand why > your patchsets always turn sour. And I'm trying to get this toxicity off > the list, because it's frankly not productive at all and it's hurting > the developer environment for everybody else. > > If everybody else seems like an asshole, maybe it's actually you? A > little introspection would be prudent. If you can't change your tone, > please just go somewhere else. I'm not interested. Let's just leave this aside for now and talk about it at LSF.