[PATCH 0/7] spanning write related cleanup

[Liam R. Howlett]

* Wei Yang <richard.weiyang at gmail.com> [250123 20:44]:
> On Thu, Jan 23, 2025 at 12:52:40PM -0500, Liam R. Howlett wrote:
> >* Wei Yang <richard.weiyang at gmail.com> [250117 00:49]:
> >> On Wed, Nov 27, 2024 at 08:31:13AM -0500, Liam R. Howlett wrote:
> >> >* Wei Yang <richard.weiyang at gmail.com> [241126 20:28]:
> >> >> Here is some cleanup related to spanning write.
> >> >
> >> >None of these fix anything, but do fiddle with code that's pretty
> >> >critical to the kernel.  Most of the changes will be immeasurable in
> >> >change but carry risk to causing subtle changes.
> >> >
> >> >Some are simple removal of returns that aren't used while others change
> >> >things because you think they are probably the equivalent.  This seems
> >> >like unnecessary chrun at this point.  I'm all for efficient code but
> >> >this is getting a bit much, some of these are just preference of what to
> >> >use that will already exist in the cpu cache.
> >> >
> >> >I'll get back to you when I dig through them, as some need a deeper look
> >> >for sure.
> >> >
> >> >Liam
> >> >
> >> 
> >> Hi, Liam
> >> 
> >> Would you mind taking a look when you have time?
> >
> >Yes, I'll have a look soon.  I don't love changes that dive deep into
> >complex code that results in no gains (performance or feature wise).
> >
> >It's also odd to have simple "this return isn't use" and things moving
> >code blocks to be executed only in certain scenarios, as the difficulty
> >to verify the latter is much higher.
> >
> >Can we please limit changes to areas where there is a performance change
> >or coupled with a change that is needed?  ie: stop sending patches that
> >change things unless it's with a feature or improvement (performance or
> >otherwise).  I'm just not convinced some of these are worth the
> >cost vs risk.
> >
> 
> Ok.
> 
> So you would drop this patch set or still want to take a look?

I was going to look at it, but after I send my reply, I received a
report of an issue caused in a certain configuration that caused the
stack frame to grow out of the configured 1024 limit, which was tracked
to a patch you added to simplify a previous function.

So, I think we should drop these patches since they don't make a
measurable difference and are not without risk.

Thanks,
Liam