From: Ingo Molnar <mingo@kernel.org>
To: Uros Bizjak <ubizjak@gmail.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [RESEND PATCH 2/2] locking/x86: Wire up sync_try_cmpxchg
Date: Fri, 29 Sep 2023 11:11:32 +0200 [thread overview]
Message-ID: <ZRaUxDeQAuMy8UY0@gmail.com> (raw)
In-Reply-To: <CAFULd4Y6OUvscbDwBL2itM89pNbo3_Q2_mKR2G4DSSbyTdD1cQ@mail.gmail.com>
* Uros Bizjak <ubizjak@gmail.com> wrote:
> On Thu, Sep 28, 2023 at 10:53 PM Ingo Molnar <mingo@kernel.org> wrote:
> >
> >
> > * Uros Bizjak <ubizjak@gmail.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
prev parent reply other threads:[~2023-09-29 9:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-25 15:08 [RESEND PATCH 1/2] locking/generic: Add generic support for sync_try_cmpxchg and its fallback Uros Bizjak
2023-09-25 15:08 ` [RESEND PATCH 2/2] locking/x86: Wire up sync_try_cmpxchg Uros Bizjak
2023-09-28 20:53 ` Ingo Molnar
2023-09-29 5:45 ` Uros Bizjak
2023-09-29 9:11 ` Ingo Molnar [this message]
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=ZRaUxDeQAuMy8UY0@gmail.com \
--to=mingo@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=ubizjak@gmail.com \
--cc=x86@kernel.org \
/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.