From: Thomas Gleixner <tglx@linutronix.de>
To: Sven Schnelle <svens@linux.ibm.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: linux-kernel@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 2/2] s390: convert to GENERIC_VDSO
Date: Mon, 03 Aug 2020 14:29:01 +0200 [thread overview]
Message-ID: <87ft93ncaa.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200803055645.79042-3-svens@linux.ibm.com>
Sven Schnelle <svens@linux.ibm.com> writes:
> - CPUCLOCK_VIRT is now handled with a syscall fallback, which might
> be slower/less accurate than the old implementation.
I can understand the slower, but why does it become less accurate?
> Performance number from my system do 100 mio gettimeofday() calls:
>
> Plain syscall: 8.6s
> Generic VDSO: 1.3s
> old ASM VDSO: 1s
>
> So it's a bit slower but still much faster than syscalls.
Where is the overhead coming from?
> +static inline u64 __arch_get_hw_counter(s32 clock_mode)
> +{
> + const struct vdso_data *vdso = __arch_get_vdso_data();
> + u64 adj, now;
> + int cnt;
> +
> + do {
> + do {
> + cnt = READ_ONCE(vdso->arch.tb_update_cnt);
> + } while (cnt & 1);
smp_rmb() ?
> + now = get_tod_clock();
> + adj = vdso->arch.tod_steering_end - now;
> + if (unlikely((s64) adj > 0))
> + now += (vdso->arch.tod_steering_delta < 0) ? (adj >> 15) : -(adj >> 15);
smp_rmb() ?
> + } while (cnt != READ_ONCE(vdso->arch.tb_update_cnt));
> + return now;
> if (ptff_query(PTFF_QTO) && ptff(&qto, sizeof(qto), PTFF_QTO) == 0)
> lpar_offset = qto.tod_epoch_difference;
> @@ -599,6 +550,13 @@ static int stp_sync_clock(void *data)
> if (stp_info.todoff[0] || stp_info.todoff[1] ||
> stp_info.todoff[2] || stp_info.todoff[3] ||
> stp_info.tmd != 2) {
> + vdso_data->arch.tb_update_cnt++;
> + /*
> + * This barrier isn't really needed as we're called
> + * from stop_machine_cpuslocked(). However it doesn't
> + * hurt in case the code gets changed.
> + */
> + smp_wmb();
WMB without a corresponding RMB and an explanation what's ordered
against what is voodoo at best.
> rc = chsc_sstpc(stp_page, STP_OP_SYNC, 0,
> &clock_delta);
> if (rc == 0) {
> @@ -609,6 +567,8 @@ static int stp_sync_clock(void *data)
> if (rc == 0 && stp_info.tmd != 2)
> rc = -EAGAIN;
> }
> + smp_wmb(); /* see comment above */
See my comments above :)
Thanks,
tglx
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de>
To: Sven Schnelle <svens@linux.ibm.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: linux-kernel@vger.kernel.org, Sven Schnelle <svens@linux.ibm.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 2/2] s390: convert to GENERIC_VDSO
Date: Mon, 03 Aug 2020 14:29:01 +0200 [thread overview]
Message-ID: <87ft93ncaa.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200803055645.79042-3-svens@linux.ibm.com>
Sven Schnelle <svens@linux.ibm.com> writes:
> - CPUCLOCK_VIRT is now handled with a syscall fallback, which might
> be slower/less accurate than the old implementation.
I can understand the slower, but why does it become less accurate?
> Performance number from my system do 100 mio gettimeofday() calls:
>
> Plain syscall: 8.6s
> Generic VDSO: 1.3s
> old ASM VDSO: 1s
>
> So it's a bit slower but still much faster than syscalls.
Where is the overhead coming from?
> +static inline u64 __arch_get_hw_counter(s32 clock_mode)
> +{
> + const struct vdso_data *vdso = __arch_get_vdso_data();
> + u64 adj, now;
> + int cnt;
> +
> + do {
> + do {
> + cnt = READ_ONCE(vdso->arch.tb_update_cnt);
> + } while (cnt & 1);
smp_rmb() ?
> + now = get_tod_clock();
> + adj = vdso->arch.tod_steering_end - now;
> + if (unlikely((s64) adj > 0))
> + now += (vdso->arch.tod_steering_delta < 0) ? (adj >> 15) : -(adj >> 15);
smp_rmb() ?
> + } while (cnt != READ_ONCE(vdso->arch.tb_update_cnt));
> + return now;
> if (ptff_query(PTFF_QTO) && ptff(&qto, sizeof(qto), PTFF_QTO) == 0)
> lpar_offset = qto.tod_epoch_difference;
> @@ -599,6 +550,13 @@ static int stp_sync_clock(void *data)
> if (stp_info.todoff[0] || stp_info.todoff[1] ||
> stp_info.todoff[2] || stp_info.todoff[3] ||
> stp_info.tmd != 2) {
> + vdso_data->arch.tb_update_cnt++;
> + /*
> + * This barrier isn't really needed as we're called
> + * from stop_machine_cpuslocked(). However it doesn't
> + * hurt in case the code gets changed.
> + */
> + smp_wmb();
WMB without a corresponding RMB and an explanation what's ordered
against what is voodoo at best.
> rc = chsc_sstpc(stp_page, STP_OP_SYNC, 0,
> &clock_delta);
> if (rc == 0) {
> @@ -609,6 +567,8 @@ static int stp_sync_clock(void *data)
> if (rc == 0 && stp_info.tmd != 2)
> rc = -EAGAIN;
> }
> + smp_wmb(); /* see comment above */
See my comments above :)
Thanks,
tglx
next prev parent reply other threads:[~2020-08-03 12:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-03 5:56 [PATCH RFC] s390: convert to GENERIC_VDSO Sven Schnelle
2020-08-03 5:56 ` [PATCH 1/2] vdso: allow to add architecture-specific vdso data Sven Schnelle
2020-08-03 12:13 ` Thomas Gleixner
2020-08-03 14:01 ` Sven Schnelle
2020-08-03 5:56 ` [PATCH 2/2] s390: convert to GENERIC_VDSO Sven Schnelle
2020-08-03 12:29 ` Thomas Gleixner [this message]
2020-08-03 12:29 ` Thomas Gleixner
2020-08-03 14:09 ` Sven Schnelle
2020-08-03 16:05 ` Thomas Gleixner
2020-08-03 18:44 ` Heiko Carstens
2020-08-03 19:27 ` Thomas Gleixner
2020-08-03 20:12 ` Heiko Carstens
2020-08-04 9:22 ` Sven Schnelle
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=87ft93ncaa.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=svens@linux.ibm.com \
--cc=vincenzo.frascino@arm.com \
/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.