On Fri, 2007-06-01 at 20:30 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > So, having two interfaces, one fast and one accurate is the right
> > > answer IMHO.
> >
> > In the case of lockstat you have two cases fast and functional, and
> > non-functional .. Right
On Fri, 2007-06-01 at 20:43 +0200, Peter Zijlstra wrote:
> On Fri, 2007-06-01 at 09:11 -0700, Daniel Walker wrote:
> > On Fri, 2007-06-01 at 17:52 +0200, Peter Zijlstra wrote:
>
> > > The whole issue is that you don't have any control over what clocksource
> > > you'll end up with. If it so happen
On Fri, 2007-06-01 at 20:19 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > > > I see sched_clock() as fast first, accurate second. Whereas the
> > > > > clocksource thing is accurate first, fast second.
> > > >
> > > > This is true .. However, if there is a speed
On Fri, Jun 01, 2007 at 08:30:53PM +0200, Ingo Molnar wrote:
> - better scheduling
> - better printk timestamps
> - higher-quality blktrace timestamps
- more entropy in /dev/random
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe
* Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-06-01 at 09:11 -0700, Daniel Walker wrote:
> > On Fri, 2007-06-01 at 17:52 +0200, Peter Zijlstra wrote:
>
> > > The whole issue is that you don't have any control over what clocksource
> > > you'll end up with. If it so happens that pmti
On Fri, 2007-06-01 at 09:11 -0700, Daniel Walker wrote:
> On Fri, 2007-06-01 at 17:52 +0200, Peter Zijlstra wrote:
> > The whole issue is that you don't have any control over what clocksource
> > you'll end up with. If it so happens that pmtimer gets selected your
> > whole box will crawl if its u
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > So, having two interfaces, one fast and one accurate is the right
> > answer IMHO.
>
> In the case of lockstat you have two cases fast and functional, and
> non-functional .. Right now your patch has no slow and functional
> state.
let me explai
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > > > I see sched_clock() as fast first, accurate second. Whereas the
> > > > clocksource thing is accurate first, fast second.
> > >
> > > This is true .. However, if there is a speed different it's small.
> >
> > Ugh. Have you ever compared pmtime
On Fri, 2007-06-01 at 17:52 +0200, Peter Zijlstra wrote:
> On Fri, 2007-06-01 at 08:26 -0700, Daniel Walker wrote:
> > On Fri, 2007-06-01 at 15:12 +0200, Ingo Molnar wrote:
> > > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Wed, 2007-05-30 at 19:16 +0200, Peter Zijlstra wrote:
> > >
On Fri, 2007-06-01 at 08:26 -0700, Daniel Walker wrote:
> On Fri, 2007-06-01 at 15:12 +0200, Ingo Molnar wrote:
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, 2007-05-30 at 19:16 +0200, Peter Zijlstra wrote:
> >
> > > > I think you are mistaken here; the two are similar but not
On Fri, 2007-06-01 at 15:12 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2007-05-30 at 19:16 +0200, Peter Zijlstra wrote:
>
> > > I think you are mistaken here; the two are similar but not
> > > identical.
> > >
> > > I see sched_clock() as fast first, ac
Daniel Walker <[EMAIL PROTECTED]> writes:
> On Wed, 2007-05-30 at 19:16 +0200, Peter Zijlstra wrote:
>
> > > >From the architecture perspective there are two low level clock hooks to
> > > implement one is sched_clock() , and at least one clocksource structure.
> > > Both do essentially the same
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-05-30 at 19:16 +0200, Peter Zijlstra wrote:
> > I think you are mistaken here; the two are similar but not
> > identical.
> >
> > I see sched_clock() as fast first, accurate second. Whereas the
> > clocksource thing is accurate first,
On Wed, 2007-05-30 at 19:16 +0200, Peter Zijlstra wrote:
> > >From the architecture perspective there are two low level clock hooks to
> > implement one is sched_clock() , and at least one clocksource structure.
> > Both do essentially the same thing. With timekeepings clocksource
> > structure ac
On Wed, 2007-05-30 at 10:06 -0700, Daniel Walker wrote:
> On Wed, 2007-05-30 at 15:49 +0200, Ingo Molnar wrote:
> > * Steven Rostedt <[EMAIL PROTECTED]> wrote:
> >
> > > [...] We can argue that sched_clock is "good enough". If someone
> > > wants better accounting of locks on some other arch, th
On Wed, 2007-05-30 at 15:49 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > [...] We can argue that sched_clock is "good enough". If someone
> > wants better accounting of locks on some other arch, they can simply
> > change sched_clock to be more precise.
>
> exa
On Wed, 2007-05-30 at 15:24 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > [...] Most architecture implement a jiffies sched_clock() w/ 1
> > millisecond or worse resolution.. [...]
>
> weird that you count importance by 'number of architectures', while 98%
> of th
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> [...] We can argue that sched_clock is "good enough". If someone
> wants better accounting of locks on some other arch, they can simply
> change sched_clock to be more precise.
exactly. Imprecise sched_clock() if there's a better fast clock source
>
> > [...] Most architecture implement a jiffies sched_clock() w/ 1
> > millisecond or worse resolution.. [...]
>
> weird that you count importance by 'number of architectures', while 98%
> of the installed server base is x86 or x86_64, where sched_clock() is
> pretty precise ;-)
>
I can underst
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> [...] Most architecture implement a jiffies sched_clock() w/ 1
> millisecond or worse resolution.. [...]
weird that you count importance by 'number of architectures', while 98%
of the installed server base is x86 or x86_64, where sched_clock() is
p
On Tue, 2007-05-29 at 13:28 -0700, Daniel Walker wrote:
> On Tue, 2007-05-29 at 14:52 +0200, Peter Zijlstra wrote:
> > + now = sched_clock();
> > + waittime = now - hlock->waittime_stamp;
> > +
>
> It looks like your using sched_clock() through out .. It's a little
> troubling conside
On Tue, 29 May 2007 14:52:51 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Introduce the core lock statistics code.
>
I must say that an aggregate addition of 27 ifdefs is a bit sad. And there
is some easy stuff here.
> +#ifdef CONFIG_PROVE_LOCKING
> +int prove_locking = 1;
> +module_param
On Tue, 2007-05-29 at 14:52 +0200, Peter Zijlstra wrote:
> + now = sched_clock();
> + waittime = now - hlock->waittime_stamp;
> +
It looks like your using sched_clock() through out .. It's a little
troubling considering the constraints on the function .. Most
architecture implement a
Introduce the core lock statistics code.
Lock statistics provides lock wait-time and hold-time (as well as the count
of corresponding contention and acquisitions events). Also, the first few
call-sites that encounter contention are tracked.
Lock wait-time is the time spent waiting on the lock. Th
24 matches
Mail list logo
