>
>
> I did vary HZ from 300 to 1000 HZ, I tried the 3 three different
> preemption models.
>
> With all these combinations, I still have the problem.
>
Actually, I may have observed more failure with 1000 HZ and
CONFIG_PREEMPT=y (low-latency desktop)
Also make sure that High resolution
>
>
> Also other factors to consider it is are you doing the test on a very
> loaded system? What is your platform?
>
> I have tested it positively on 32 bit, 64 bits build on Atom N450
>
> i7 first and second generation system.
>
> I did vary HZ from 300 to 1000 HZ, I tried the 3 three
> 2) tst-cputimer1.c only have CLOCK_PROCESS_CPUTIME_ID test and
> don't have any utime, stime tests.
>
Sorry, I should take a couple minutes break before pressing send to be
sure that I have said everything :-)
CLOCK_PROCESS_CPUTIME_ID is user space name for kernel space
CPUCLOCK_SCHED clock.
On Fri, 2013-04-26 at 22:15 -0400, KOSAKI Motohiro wrote:
> On Fri, Apr 26, 2013 at 9:51 PM, Olivier Langlois
> wrote:
> > On Fri, 2013-04-26 at 15:08 -0400, KOSAKI Motohiro wrote:
> >> > I need to add that I can only confirm that to be true with
> >> > sum_exec_runtime.
> >> >
> >> > To affirm
On Fri, Apr 26, 2013 at 9:51 PM, Olivier Langlois
wrote:
> On Fri, 2013-04-26 at 15:08 -0400, KOSAKI Motohiro wrote:
>> > I need to add that I can only confirm that to be true with
>> > sum_exec_runtime.
>> >
>> > To affirm it to be true for stime and utime would require more
>> > investigation.
On Fri, 2013-04-26 at 15:08 -0400, KOSAKI Motohiro wrote:
> > I need to add that I can only confirm that to be true with
> > sum_exec_runtime.
> >
> > To affirm it to be true for stime and utime would require more
> > investigation. I didn't look them at all. I was only concerned with
> >
> I need to add that I can only confirm that to be true with
> sum_exec_runtime.
>
> To affirm it to be true for stime and utime would require more
> investigation. I didn't look them at all. I was only concerned with
> sum_exec_runtime.
>
> I will prepare a v2 of the patch accounting all the
On Fri, 2013-04-26 at 00:40 -0400, Olivier Langlois wrote:
> On Fri, 2013-04-19 at 11:08 -0700, KOSAKI Motohiro wrote:
> > On Fri, Apr 19, 2013 at 10:38 AM, KOSAKI Motohiro
> > wrote:
> > >> I feel we are hitting the same issue than this patch:
> > >> https://lkml.org/lkml/2013/4/5/116
> > >>
> >
On Fri, 2013-04-26 at 00:40 -0400, Olivier Langlois wrote:
On Fri, 2013-04-19 at 11:08 -0700, KOSAKI Motohiro wrote:
On Fri, Apr 19, 2013 at 10:38 AM, KOSAKI Motohiro
kosaki.motoh...@gmail.com wrote:
I feel we are hitting the same issue than this patch:
I need to add that I can only confirm that to be true with
sum_exec_runtime.
To affirm it to be true for stime and utime would require more
investigation. I didn't look them at all. I was only concerned with
sum_exec_runtime.
I will prepare a v2 of the patch accounting all the feedbacks
On Fri, 2013-04-26 at 15:08 -0400, KOSAKI Motohiro wrote:
I need to add that I can only confirm that to be true with
sum_exec_runtime.
To affirm it to be true for stime and utime would require more
investigation. I didn't look them at all. I was only concerned with
sum_exec_runtime.
On Fri, Apr 26, 2013 at 9:51 PM, Olivier Langlois
oliv...@trillion01.com wrote:
On Fri, 2013-04-26 at 15:08 -0400, KOSAKI Motohiro wrote:
I need to add that I can only confirm that to be true with
sum_exec_runtime.
To affirm it to be true for stime and utime would require more
On Fri, 2013-04-26 at 22:15 -0400, KOSAKI Motohiro wrote:
On Fri, Apr 26, 2013 at 9:51 PM, Olivier Langlois
oliv...@trillion01.com wrote:
On Fri, 2013-04-26 at 15:08 -0400, KOSAKI Motohiro wrote:
I need to add that I can only confirm that to be true with
sum_exec_runtime.
To affirm
2) tst-cputimer1.c only have CLOCK_PROCESS_CPUTIME_ID test and
don't have any utime, stime tests.
Sorry, I should take a couple minutes break before pressing send to be
sure that I have said everything :-)
CLOCK_PROCESS_CPUTIME_ID is user space name for kernel space
CPUCLOCK_SCHED clock.
Also other factors to consider it is are you doing the test on a very
loaded system? What is your platform?
I have tested it positively on 32 bit, 64 bits build on Atom N450
i7 first and second generation system.
I did vary HZ from 300 to 1000 HZ, I tried the 3 three different
I did vary HZ from 300 to 1000 HZ, I tried the 3 three different
preemption models.
With all these combinations, I still have the problem.
Actually, I may have observed more failure with 1000 HZ and
CONFIG_PREEMPT=y (low-latency desktop)
Also make sure that High resolution timers
On Fri, 2013-04-19 at 11:08 -0700, KOSAKI Motohiro wrote:
> On Fri, Apr 19, 2013 at 10:38 AM, KOSAKI Motohiro
> wrote:
> >> I feel we are hitting the same issue than this patch:
> >> https://lkml.org/lkml/2013/4/5/116
> >>
> >> I'm adding Kosaki in Cc, who proposed roughly the same fix.
> >
> >
On Fri, 2013-04-19 at 11:08 -0700, KOSAKI Motohiro wrote:
On Fri, Apr 19, 2013 at 10:38 AM, KOSAKI Motohiro
kosaki.motoh...@gmail.com wrote:
I feel we are hitting the same issue than this patch:
https://lkml.org/lkml/2013/4/5/116
I'm adding Kosaki in Cc, who proposed roughly the same
On Fri, Apr 19, 2013 at 10:38 AM, KOSAKI Motohiro
wrote:
>> I feel we are hitting the same issue than this patch:
>> https://lkml.org/lkml/2013/4/5/116
>>
>> I'm adding Kosaki in Cc, who proposed roughly the same fix.
>
> Thanks to CCing. I'm now sitting LSF and I can't read whole tons emails.
>
> I feel we are hitting the same issue than this patch:
> https://lkml.org/lkml/2013/4/5/116
>
> I'm adding Kosaki in Cc, who proposed roughly the same fix.
Thanks to CCing. I'm now sitting LSF and I can't read whole tons emails.
However the fix is definitely same and I definitely agree this
2013/4/12 Peter Zijlstra :
> On Fri, 2013-04-12 at 12:50 +0200, Peter Zijlstra wrote:
>
>> I'll try and dig through the rest of your email later.. sorry for
>> being
>> a tad slow etc.
>
>
> So at thread_group_cputimer() we initialize the cputimer->cputime state
> by using thread_group_cputime()
2013/4/12 Peter Zijlstra pet...@infradead.org:
On Fri, 2013-04-12 at 12:50 +0200, Peter Zijlstra wrote:
I'll try and dig through the rest of your email later.. sorry for
being
a tad slow etc.
So at thread_group_cputimer() we initialize the cputimer-cputime state
by using
I feel we are hitting the same issue than this patch:
https://lkml.org/lkml/2013/4/5/116
I'm adding Kosaki in Cc, who proposed roughly the same fix.
Thanks to CCing. I'm now sitting LSF and I can't read whole tons emails.
However the fix is definitely same and I definitely agree this
On Fri, Apr 19, 2013 at 10:38 AM, KOSAKI Motohiro
kosaki.motoh...@gmail.com wrote:
I feel we are hitting the same issue than this patch:
https://lkml.org/lkml/2013/4/5/116
I'm adding Kosaki in Cc, who proposed roughly the same fix.
Thanks to CCing. I'm now sitting LSF and I can't read whole
On Fri, 2013-04-12 at 17:55 +0200, Peter Zijlstra wrote:
> On Fri, 2013-04-12 at 12:50 +0200, Peter Zijlstra wrote:
>
> > I'll try and dig through the rest of your email later.. sorry for
> > being
> > a tad slow etc.
>
>
> So at thread_group_cputimer() we initialize the cputimer->cputime
On Fri, 2013-04-12 at 17:55 +0200, Peter Zijlstra wrote:
On Fri, 2013-04-12 at 12:50 +0200, Peter Zijlstra wrote:
I'll try and dig through the rest of your email later.. sorry for
being
a tad slow etc.
So at thread_group_cputimer() we initialize the cputimer-cputime state
by using
On Fri, 2013-04-12 at 11:16 +0200, Peter Zijlstra wrote:
> On Wed, 2013-04-10 at 11:48 -0400, Olivier Langlois wrote:
> > Please explain how expensive it is. All I am seeing is a couple of
> > additions.
>
> Let me start with this, since your earlier argument also refers to
> this.
>
> So yes it
On Fri, 2013-04-12 at 11:16 +0200, Peter Zijlstra wrote:
On Wed, 2013-04-10 at 11:48 -0400, Olivier Langlois wrote:
Please explain how expensive it is. All I am seeing is a couple of
additions.
Let me start with this, since your earlier argument also refers to
this.
So yes it does look
On Fri, 2013-04-12 at 12:50 +0200, Peter Zijlstra wrote:
> I'll try and dig through the rest of your email later.. sorry for
> being
> a tad slow etc.
So at thread_group_cputimer() we initialize the cputimer->cputime state
by using thread_group_cputime() which iterates all tasks of the process
On Wed, 2013-04-10 at 11:48 -0400, Olivier Langlois wrote:
>
> You have valid concerns and I will attempt to clarify the changes I
> propose. Before I do, realise that as a first time patcher, I
> sincerely
> attempted to minimize the changes required to fix the posix cputimers.
Right, I suspect
On Wed, 2013-04-10 at 11:48 -0400, Olivier Langlois wrote:
> If it is important to stop it then the code will require a fix anyway.
>
> 1.
> As you could start it
> indefinitely with 0 timers if calling posix_cpu_timer_set() does not
> end
> up arming a timer or
>
> 2.
>
> Having one periodic
On Wed, 2013-04-10 at 11:48 -0400, Olivier Langlois wrote:
> Please explain how expensive it is. All I am seeing is a couple of
> additions.
Let me start with this, since your earlier argument also refers to
this.
So yes it does look simple and straight fwd, only one addition. However
its an
On Wed, 2013-04-10 at 11:48 -0400, Olivier Langlois wrote:
Please explain how expensive it is. All I am seeing is a couple of
additions.
Let me start with this, since your earlier argument also refers to
this.
So yes it does look simple and straight fwd, only one addition. However
its an
On Wed, 2013-04-10 at 11:48 -0400, Olivier Langlois wrote:
If it is important to stop it then the code will require a fix anyway.
1.
As you could start it
indefinitely with 0 timers if calling posix_cpu_timer_set() does not
end
up arming a timer or
2.
Having one periodic timer. The
On Wed, 2013-04-10 at 11:48 -0400, Olivier Langlois wrote:
You have valid concerns and I will attempt to clarify the changes I
propose. Before I do, realise that as a first time patcher, I
sincerely
attempted to minimize the changes required to fix the posix cputimers.
Right, I suspect some
On Fri, 2013-04-12 at 12:50 +0200, Peter Zijlstra wrote:
I'll try and dig through the rest of your email later.. sorry for
being
a tad slow etc.
So at thread_group_cputimer() we initialize the cputimer-cputime state
by using thread_group_cputime() which iterates all tasks of the process
and
On Wed, 2013-04-10 at 13:35 +0200, Peter Zijlstra wrote:
> On Fri, 2013-04-05 at 13:59 -0400, Olivier Langlois wrote:
> > Process timers are moving fasters than their corresponding
> > cpu clock for various reasons:
> >
> > 1. There is a race condition when getting a timer sample that makes the
On Wed, 2013-04-10 at 13:35 +0200, Peter Zijlstra wrote:
> On Fri, 2013-04-05 at 13:59 -0400, Olivier Langlois wrote:
> > Process timers are moving fasters than their corresponding
> > cpu clock for various reasons:
> >
> > 1. There is a race condition when getting a timer sample that makes the
On Fri, 2013-04-05 at 13:59 -0400, Olivier Langlois wrote:
> Process timers are moving fasters than their corresponding
> cpu clock for various reasons:
>
> 1. There is a race condition when getting a timer sample that makes the sample
>be smaller than it should leading to setting the timer
On Fri, 2013-04-05 at 13:59 -0400, Olivier Langlois wrote:
Process timers are moving fasters than their corresponding
cpu clock for various reasons:
1. There is a race condition when getting a timer sample that makes the sample
be smaller than it should leading to setting the timer
On Wed, 2013-04-10 at 13:35 +0200, Peter Zijlstra wrote:
On Fri, 2013-04-05 at 13:59 -0400, Olivier Langlois wrote:
Process timers are moving fasters than their corresponding
cpu clock for various reasons:
1. There is a race condition when getting a timer sample that makes the
sample
On Wed, 2013-04-10 at 13:35 +0200, Peter Zijlstra wrote:
On Fri, 2013-04-05 at 13:59 -0400, Olivier Langlois wrote:
Process timers are moving fasters than their corresponding
cpu clock for various reasons:
1. There is a race condition when getting a timer sample that makes the
sample
Process timers are moving fasters than their corresponding
cpu clock for various reasons:
1. There is a race condition when getting a timer sample that makes the sample
be smaller than it should leading to setting the timer expiration to soon.
2. When initializing the cputimer, by including
Process timers are moving fasters than their corresponding
cpu clock for various reasons:
1. There is a race condition when getting a timer sample that makes the sample
be smaller than it should leading to setting the timer expiration to soon.
2. When initializing the cputimer, by including
44 matches
Mail list logo
