On Mon, 9 Oct 2017, Pavel Tatashin wrote:
> > Urgh, that's horrific.
> >
> > Can't we simply make sched_clock() go earlier? (we're violating "notsc"
> > in any case and really should kill that option).
> >
> > Then we can do something like so on top...
> >
>
> Hi Peter,
>
> I've been thinking
On Wed, Oct 18, 2017 at 6:01 AM, Dou Liyang wrote:
> Hi Pasha,
>
> Sorry to reply you so late.
>
> I have test the TSC sync in our machine with DR(Dynamic Reconfiguration)
> Linux kernel: Linux-4.14.0-rc5
> NUMA nodes: 4 node.
> Use clock_gettime() to reach nano-second accuracy.
>
> It is OK
Hi Pasha,
Sorry to reply you so late.
I have test the TSC sync in our machine with DR(Dynamic Reconfiguration)
Linux kernel: Linux-4.14.0-rc5
NUMA nodes: 4 node.
Use clock_gettime() to reach nano-second accuracy.
It is OK that we setup our reconfigurable with "tsc=unstable".
Thanks,
Urgh, that's horrific.
Can't we simply make sched_clock() go earlier? (we're violating "notsc"
in any case and really should kill that option).
Then we can do something like so on top...
Hi Peter,
I've been thinking about your proposal, and I have one concern:
sched_clock() can be implemen
Hi, Pasha
At 09/28/2017 09:11 PM, Pasha Tatashin wrote:
It will be best if we can support TSC sync capability in x86, but seems
is not easy.
Sure, your hardware achieving sync would be best, but even if it does
not, we can still use TSC. Using notsc simple because you fail to sync
TSCs is quit
It will be best if we can support TSC sync capability in x86, but seems
is not easy.
Sure, your hardware achieving sync would be best, but even if it does
not, we can still use TSC. Using notsc simple because you fail to sync
TSCs is quite crazy.
The thing is, we need to support unsync'ed TSC i
On Thu, 28 Sep 2017, Peter Zijlstra wrote:
> On Thu, Sep 28, 2017 at 06:03:05PM +0800, Dou Liyang wrote:
> > At 09/28/2017 02:09 AM, Peter Zijlstra wrote:
> > > On Wed, Sep 27, 2017 at 08:05:48PM +0200, Peter Zijlstra wrote:
> > > > On Wed, Sep 27, 2017 at 09:52:36PM +0800, Dou Liyang wrote:
> > >
On Thu, Sep 28, 2017 at 06:03:05PM +0800, Dou Liyang wrote:
> At 09/28/2017 02:09 AM, Peter Zijlstra wrote:
> > On Wed, Sep 27, 2017 at 08:05:48PM +0200, Peter Zijlstra wrote:
> > > On Wed, Sep 27, 2017 at 09:52:36PM +0800, Dou Liyang wrote:
> > > > We do not want to do that. Because, we use "notsc
Hi Peter,
At 09/28/2017 02:09 AM, Peter Zijlstra wrote:
On Wed, Sep 27, 2017 at 08:05:48PM +0200, Peter Zijlstra wrote:
On Wed, Sep 27, 2017 at 09:52:36PM +0800, Dou Liyang wrote:
We do not want to do that. Because, we use "notsc" to support Dynamic
Reconfiguration[1].
AFAIK, this feature en
On Wed, Sep 27, 2017 at 03:45:06PM +0100, Russell King - ARM Linux wrote:
> On Wed, Aug 30, 2017 at 02:03:22PM -0400, Pavel Tatashin wrote:
> > In Linux printk() can output timestamps next to every line. This is very
> > useful for tracking regressions, and finding places that can be optimized.
>
On Wed, Sep 27, 2017 at 08:05:48PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 27, 2017 at 09:52:36PM +0800, Dou Liyang wrote:
> > We do not want to do that. Because, we use "notsc" to support Dynamic
> > Reconfiguration[1].
> >
> > AFAIK, this feature enables hot-add system board which contains CP
On Wed, Sep 27, 2017 at 09:52:36PM +0800, Dou Liyang wrote:
> We do not want to do that. Because, we use "notsc" to support Dynamic
> Reconfiguration[1].
>
> AFAIK, this feature enables hot-add system board which contains CPUs
> and memories. But the CPUs in different board may have different TSCs
Hi Dou,
This makes sense. The current sched_clock_early() approach does not
break it because with notsc TSC is used early in boot, and later
stopped. But, notsc must stay.
Peter,
So, we could either expend sched_clock() with another static branch for
early clock, or use what I proposed. IMO
Hi Russell,
This might be so for ARM, and in fact if you look at my SPARC
implementation, I simply made source clock initialize early, so regular
sched_clock() is used. As on SPARC, we use either %tick or %stick
registers with frequency determined via OpenFrimware. But, on x86 there
are dozen
On Wed, Aug 30, 2017 at 02:03:22PM -0400, Pavel Tatashin wrote:
> In Linux printk() can output timestamps next to every line. This is very
> useful for tracking regressions, and finding places that can be optimized.
> However, the timestamps are available only later in boot. On smaller
> machines
Hi Pasha, Peter
At 09/27/2017 09:16 PM, Pasha Tatashin wrote:
Hi Peter,
I am totally happy with removing notsc. This certainly simplifies the
sched_clock code. Are there any issues with removing existing kernel
parameters that I should be aware of?
We do not want to do that. Because, we use
Hi Peter,
I am totally happy with removing notsc. This certainly simplifies the
sched_clock code. Are there any issues with removing existing kernel
parameters that I should be aware of?
Thank you,
Pasha
On 09/27/2017 09:10 AM, Peter Zijlstra wrote:
On Wed, Sep 27, 2017 at 02:58:57PM +0200,
On Wed, Sep 27, 2017 at 02:58:57PM +0200, Peter Zijlstra wrote:
> (we're violating "notsc" in any case and really should kill that
> option).
Something like so; in particular simple_udelay_calibrate() will issue
RDTSC _way_ early, so there is absolutely no point in then pretending we
can't use RDT
On Wed, Aug 30, 2017 at 02:03:22PM -0400, Pavel Tatashin wrote:
> In Linux printk() can output timestamps next to every line. This is very
> useful for tracking regressions, and finding places that can be optimized.
> However, the timestamps are available only later in boot. On smaller
> machines
In Linux printk() can output timestamps next to every line. This is very
useful for tracking regressions, and finding places that can be optimized.
However, the timestamps are available only later in boot. On smaller
machines it is insignificant amount of time, but on larger it can be many
seconds
20 matches
Mail list logo
