From: Sven Schnelle <svens@linux.ibm.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
linux-s390@vger.kernel.org, hca@linux.ibm.com
Subject: Re: [PATCH 2/2] s390: convert to GENERIC_VDSO
Date: Mon, 03 Aug 2020 16:09:48 +0200 [thread overview]
Message-ID: <yt9dmu3b3jo3.fsf@linux.ibm.com> (raw)
In-Reply-To: <87ft93ncaa.fsf@nanos.tec.linutronix.de> (Thomas Gleixner's message of "Mon, 03 Aug 2020 14:29:01 +0200")
Thomas Gleixner <tglx@linutronix.de> writes:
> 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?
Because we saved the system/user times as almost the last instruction
when leaving the kernel to userspace. Now it's a bit earlier, because
it is done in the C code. So it's not really related to the syscall
fallback, but the switch from assembly to C.
>> 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?
It's because we have to allocate a stackframe which we didn't do before,
and the compiler generated code is less optimized than the hand-crafted
assembly code we had before.
>> +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 :)
:-)
What do you think about my question on using vdso_write_begin/end()?
__arch_get_hw_counter() is called inside a vdso_read_retry() loop, so i
would think that just enclosing this update with vdso_write_begin/end()
should sufficient. But i'm not sure whether arch/ should call these
functions.
Thanks
Sven
next prev parent reply other threads:[~2020-08-03 14:10 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
2020-08-03 12:29 ` Thomas Gleixner
2020-08-03 14:09 ` Sven Schnelle [this message]
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=yt9dmu3b3jo3.fsf@linux.ibm.com \
--to=svens@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--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.