[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZRaUxDeQAuMy8UY0@gmail.com>
Date:   Fri, 29 Sep 2023 11:11:32 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Uros Bizjak <ubizjak@...il.com>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [RESEND PATCH 2/2] locking/x86: Wire up sync_try_cmpxchg
* Uros Bizjak <ubizjak@...il.com> wrote:
> On Thu, Sep 28, 2023 at 10:53 PM Ingo Molnar <mingo@...nel.org> wrote:
> >
> >
> > * Uros Bizjak <ubizjak@...il.com> wrote:
> >
> > > Implement target specific support for sync_try_cmpxchg.
> >
> > Could you please provide a before/after description of how
> > this improves things exactly?
> 
> The improvement [1] was demonstrated in the original patch submission.
What I'm saying: please integrate the required context & arguments into the 
changelogs of the patches you submit.
Patches that change code generation should demonstrate what they achieve.
 - If existing code changes, then describe/demonstrate it with disassembly.
 - If existing code generation is unchanged, then *declare that property in 
   the changelog*, and mention that a future patch relies those changes.
You can either include that future patch in this series, or you can 
describe/demonstrate the benefits in the changelog while noting that those 
changes will come in future patches.
Your submission, as-is, provided no context whatsoever, it described only 
the 'how', not the 'why'.
Thanks,
	Ingo
Powered by blists - more mailing lists