[<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