From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: Alex Smith <alex@alex-smith.me.uk>
Cc: David Daney <ddaney.cavm@gmail.com>,
Ralf Baechle <ralf@linux-mips.org>,
Markos Chandras <markos.chandras@imgtec.com>,
linux-mips <linux-mips@linux-mips.org>,
Alex Smith <alex.smith@imgtec.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [v3, 3/3] MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime()
Date: Wed, 28 Oct 2015 11:57:45 -0700 [thread overview]
Message-ID: <56311AA9.6040101@imgtec.com> (raw)
In-Reply-To: <CAOFt0_C3QXKrZ-uta_RrR04hFMbQnNdfoJP7pZjoSSUftc7dCQ@mail.gmail.com>
On 10/28/2015 11:30 AM, Alex Smith wrote:
> On 28 October 2015 at 18:21, Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> wrote:
>>
>>
>> 1) I don't see that in code - there is no check that kernel uses actually uses R4K clocksource as primary (A), and if kernel uses R4K count as a clocksource and later switches to some more precise clocksource then there is no change in VDSO gettimeofday handling (B).
> Incorrect. The vdso_clock_mode flag in arch_clocksource_data that I
> mentioned in my previous email is copied into the VDSO data page by
> update_vsyscall(), which is called when the clocksource changes.
OK, I see this, good.
>
>> 2) The fact that MIPS kernel as today uses CP0_COUNT in any core as the same clocksource is correct only until first power saving event with CPU clock disabled (skipping Octeon). After that it is an incorrect use without an accurate synchronization and that synchronization doesn't exist.
>>
>> And I remember that today kernel uses only CPU0 CP0_COUNT to update time... may be wrong, need to check, but that could be a good code.
>>
>>> Maybe I'm missing something but I don't see anything in the generic
>>> timekeeping code that handles the same clocksource being
>>> unsynchronised or running at a different rate on different CPUs.
>>
>> (I would like to skip here the generic timekeeping code capabilities, just to restrict a discussion to HW capabilities)
>>
>>> Given that, if you think there is an issue that prevents the VDSO from
>>> using it then that would surely affect the kernel as well and needs to
>>> be fixed separately?
>>>
>>> If it really is necessary to prevent the VDSO from using a certain
>>> clocksource even though the kernel is using it, it should be a simple
>>> matter of setting clocksource.archdata.vdso_clock_mode to
>>> VDSO_CLOCK_NONE. This is how this patch stops it using the CP0 count
>>> when RDHWR is broken.
>>
>> OK, just put kernel-build time check that it is not SMP without GIC clocksource or it is Octeon. It would be enough to stop a mess.
> If you feel it's necessary then please do.
Please resend a patch with this fix.
- Leonid.
WARNING: multiple messages have this Message-ID (diff)
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: Alex Smith <alex@alex-smith.me.uk>
Cc: David Daney <ddaney.cavm@gmail.com>,
Ralf Baechle <ralf@linux-mips.org>,
Markos Chandras <markos.chandras@imgtec.com>,
linux-mips <linux-mips@linux-mips.org>,
Alex Smith <alex.smith@imgtec.com>,
linux-kernel@vger.kernel.org
Subject: Re: [v3, 3/3] MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime()
Date: Wed, 28 Oct 2015 11:57:45 -0700 [thread overview]
Message-ID: <56311AA9.6040101@imgtec.com> (raw)
Message-ID: <20151028185745.BQIcevbibQxVoIq5mhMpAFVe2_arY5FR8Iu69vUSi4Q@z> (raw)
In-Reply-To: <CAOFt0_C3QXKrZ-uta_RrR04hFMbQnNdfoJP7pZjoSSUftc7dCQ@mail.gmail.com>
On 10/28/2015 11:30 AM, Alex Smith wrote:
> On 28 October 2015 at 18:21, Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> wrote:
>>
>>
>> 1) I don't see that in code - there is no check that kernel uses actually uses R4K clocksource as primary (A), and if kernel uses R4K count as a clocksource and later switches to some more precise clocksource then there is no change in VDSO gettimeofday handling (B).
> Incorrect. The vdso_clock_mode flag in arch_clocksource_data that I
> mentioned in my previous email is copied into the VDSO data page by
> update_vsyscall(), which is called when the clocksource changes.
OK, I see this, good.
>
>> 2) The fact that MIPS kernel as today uses CP0_COUNT in any core as the same clocksource is correct only until first power saving event with CPU clock disabled (skipping Octeon). After that it is an incorrect use without an accurate synchronization and that synchronization doesn't exist.
>>
>> And I remember that today kernel uses only CPU0 CP0_COUNT to update time... may be wrong, need to check, but that could be a good code.
>>
>>> Maybe I'm missing something but I don't see anything in the generic
>>> timekeeping code that handles the same clocksource being
>>> unsynchronised or running at a different rate on different CPUs.
>>
>> (I would like to skip here the generic timekeeping code capabilities, just to restrict a discussion to HW capabilities)
>>
>>> Given that, if you think there is an issue that prevents the VDSO from
>>> using it then that would surely affect the kernel as well and needs to
>>> be fixed separately?
>>>
>>> If it really is necessary to prevent the VDSO from using a certain
>>> clocksource even though the kernel is using it, it should be a simple
>>> matter of setting clocksource.archdata.vdso_clock_mode to
>>> VDSO_CLOCK_NONE. This is how this patch stops it using the CP0 count
>>> when RDHWR is broken.
>>
>> OK, just put kernel-build time check that it is not SMP without GIC clocksource or it is Octeon. It would be enough to stop a mess.
> If you feel it's necessary then please do.
Please resend a patch with this fix.
- Leonid.
next prev parent reply other threads:[~2015-10-28 18:57 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-28 10:03 [PATCH 0/3] MIPS VDSO support Markos Chandras
2015-09-28 10:03 ` Markos Chandras
2015-09-28 10:10 ` [PATCH 1/3] MIPS: Initial implementation of a VDSO Markos Chandras
2015-09-28 10:10 ` Markos Chandras
2015-09-28 10:54 ` Alex Smith
2015-09-28 13:07 ` Matthew Fortune
2015-09-28 13:07 ` Matthew Fortune
2015-11-20 18:15 ` Maciej W. Rozycki
2015-10-09 8:05 ` [PATCH v2 " Markos Chandras
2015-10-09 8:05 ` Markos Chandras
2015-10-21 8:54 ` [PATCH v3 " Markos Chandras
2015-10-21 8:54 ` Markos Chandras
2015-09-28 10:11 ` [PATCH 2/3] irqchip: irq-mips-gic: Provide function to map GIC user section Markos Chandras
2015-09-28 10:11 ` Markos Chandras
2015-09-28 10:55 ` Marc Zyngier
2015-09-28 14:16 ` Qais Yousef
2015-09-28 14:16 ` Qais Yousef
2015-09-28 15:03 ` Marc Zyngier
2015-10-05 8:22 ` Markos Chandras
2015-10-05 8:22 ` Markos Chandras
2015-10-12 9:40 ` [PATCH v2 " Markos Chandras
2015-10-12 9:40 ` Markos Chandras
2015-10-12 9:51 ` Marc Zyngier
2015-10-12 10:16 ` Thomas Gleixner
2015-10-15 9:37 ` Qais Yousef
2015-10-15 9:37 ` Qais Yousef
2015-10-15 10:18 ` Thomas Gleixner
2015-09-28 10:12 ` [PATCH 3/3] MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime() Markos Chandras
2015-09-28 10:12 ` Markos Chandras
2015-09-28 13:15 ` kbuild test robot
2015-09-28 13:15 ` kbuild test robot
2015-10-12 10:24 ` [PATCH v2 " Markos Chandras
2015-10-12 10:24 ` Markos Chandras
2015-10-21 8:57 ` [PATCH v3 " Markos Chandras
2015-10-21 8:57 ` Markos Chandras
2015-10-23 1:41 ` [v3, " Leonid Yegoshin
2015-10-23 1:41 ` Leonid Yegoshin
2015-10-27 14:47 ` Ralf Baechle
2015-10-27 20:46 ` Leonid Yegoshin
2015-10-27 20:46 ` Leonid Yegoshin
2015-10-27 21:02 ` David Daney
2015-10-27 21:15 ` Leonid Yegoshin
2015-10-27 21:15 ` Leonid Yegoshin
2015-10-27 21:44 ` David Daney
2015-10-27 21:49 ` Leonid Yegoshin
2015-10-27 21:49 ` Leonid Yegoshin
2015-10-28 10:20 ` Alex Smith
2015-10-28 18:21 ` Leonid Yegoshin
2015-10-28 18:21 ` Leonid Yegoshin
2015-10-28 18:30 ` Alex Smith
2015-10-28 18:57 ` Leonid Yegoshin [this message]
2015-10-28 18:57 ` Leonid Yegoshin
2015-10-28 19:04 ` Alex Smith
2015-10-28 19:28 ` Leonid Yegoshin
2015-10-28 19:28 ` Leonid Yegoshin
2015-10-28 19:55 ` Alex Smith
2015-10-28 20:15 ` Leonid Yegoshin
2015-10-28 20:15 ` Leonid Yegoshin
2016-01-25 22:36 ` [PATCH v3 " Hauke Mehrtens
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=56311AA9.6040101@imgtec.com \
--to=leonid.yegoshin@imgtec.com \
--cc=alex.smith@imgtec.com \
--cc=alex@alex-smith.me.uk \
--cc=ddaney.cavm@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=markos.chandras@imgtec.com \
--cc=ralf@linux-mips.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.