Hi Laurent,
On Tue, 2014-04-01 at 15:49 +0200, Laurent Pinchart wrote:
> Hi Olivier,
>
> On Sunday 30 March 2014 00:23:01 Olivier Langlois wrote:
> > Hi Laurent,
> >
> > > > Yes. ffmpeg uses wall clock time to create timestamps for audio packets
> > &
Hi Laurent,
On Tue, 2014-04-01 at 15:49 +0200, Laurent Pinchart wrote:
Hi Olivier,
On Sunday 30 March 2014 00:23:01 Olivier Langlois wrote:
Hi Laurent,
Yes. ffmpeg uses wall clock time to create timestamps for audio packets
from ALSA device.
OK. I suppose I shouldn't drop
Hi Laurent,
> > Yes. ffmpeg uses wall clock time to create timestamps for audio packets from
> > ALSA device.
>
> OK. I suppose I shouldn't drop support for the realtime clock like I wanted
> to
> then :-)
>
> > There is a bug in ffmpeg describing problems to synchronize audio and
> > the
Hi Laurent,
Yes. ffmpeg uses wall clock time to create timestamps for audio packets from
ALSA device.
OK. I suppose I shouldn't drop support for the realtime clock like I wanted
to
then :-)
There is a bug in ffmpeg describing problems to synchronize audio and
the video from a
> > >
> > > Before applying this, I'm curious, do you have a use case for realtime
> > > time stamps ?
> >
> > Yes. ffmpeg uses wall clock time to create timestamps for audio packets from
> > ALSA device.
>
> OK. I suppose I shouldn't drop support for the realtime clock like I wanted
> to
>
Hi Laurent,
On Fri, 2014-03-28 at 17:20 +0100, Laurent Pinchart wrote:
> Hi Olivier,
>
> Thank you for the patch.
>
> On Friday 28 March 2014 01:42:38 Olivier Langlois wrote:
> > timestamps in v4l2 buffers returned to userspace are updated in
> > uvc_video_clock_upd
Hi Laurent,
On Fri, 2014-03-28 at 17:20 +0100, Laurent Pinchart wrote:
Hi Olivier,
Thank you for the patch.
On Friday 28 March 2014 01:42:38 Olivier Langlois wrote:
timestamps in v4l2 buffers returned to userspace are updated in
uvc_video_clock_update() which uses timestamps fetched
Before applying this, I'm curious, do you have a use case for realtime
time stamps ?
Yes. ffmpeg uses wall clock time to create timestamps for audio packets from
ALSA device.
OK. I suppose I shouldn't drop support for the realtime clock like I wanted
to
then :-)
There
with ffmpeg:
ffmpeg -y -f v4l2 -input_format yuyv422 -video_size 640x480 -framerate 30 -i
/dev/video0 \
-f alsa -acodec pcm_s16le -ar 16000 -ac 1 -i default \
-c:v libx264 -preset ultrafast \
-c:a libfdk_aac \
out.mkv
and inspecting the v4l2 input starting timestamp.
Signed-off-by: Olivier
with ffmpeg:
ffmpeg -y -f v4l2 -input_format yuyv422 -video_size 640x480 -framerate 30 -i
/dev/video0 \
-f alsa -acodec pcm_s16le -ar 16000 -ac 1 -i default \
-c:v libx264 -preset ultrafast \
-c:a libfdk_aac \
out.mkv
and inspecting the v4l2 input starting timestamp.
Signed-off-by: Olivier
has proven to work is
to reenable the irqs during the function rtl92ce_hw_init().
I think that it is safe doing so since the device interrupt will only be
enabled after the init function succeed.
Signed-off-by: Olivier Langlois
Cc: Stable
---
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 18
rtl_ps_enable_nic() is called from loops that will loop until this function
returns true or a
maximum number of retries is performed.
hw_init() returns non-zero on error. In that situation return false to
restore the original design intent to retry hw init when it fails.
Signed-off-by: Olivier
rtl_ps_enable_nic() is called from loops that will loop until this function
returns true or a
maximum number of retries is performed.
hw_init() returns non-zero on error. In that situation return false to
restore the original design intent to retry hw init when it fails.
Signed-off-by: Olivier
() with the irqs disabled
but a quick and dirty solution that has proven to work is
to reenable the irqs during the function rtl92ce_hw_init().
I think that it is safe doing so since the device interrupt will only be
enabled after the init function succeed.
Signed-off-by: Olivier Langlois oliv
has proven to work is
to reenable the irqs during the function rtl92ce_hw_init().
I think that it is safe doing so since the device interrupt will only be
enabled after the init function succeed.
Signed-off-by: Olivier Langlois
---
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 18
On Thu, 2014-01-30 at 14:19 -0600, Larry Finger wrote:
> On 01/30/2014 12:22 AM, Olivier Langlois wrote:
> > Signed-off-by: Olivier Langlois
> > ---
> > drivers/net/wireless/rtlwifi/ps.c | 2 +-
> > drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 18 +
rtl_ps_enable_nic() is called from loops that will loop until this function
returns true or a
maximum number of retries is performed.
hw_init() returns non-zero on error. In that situation return false to
restore the original design intent to retry hw init when it fails.
Signed-off-by: Olivier
rtl_ps_enable_nic() is called from loops that will loop until this function
returns true or a
maximum number of retries is performed.
hw_init() returns non-zero on error. In that situation return false to
restore the original design intent to retry hw init when it fails.
Signed-off-by: Olivier
On Thu, 2014-01-30 at 14:19 -0600, Larry Finger wrote:
On 01/30/2014 12:22 AM, Olivier Langlois wrote:
Signed-off-by: Olivier Langlois oliv...@trillion01.com
---
drivers/net/wireless/rtlwifi/ps.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 18
() with the irqs disabled
but a quick and dirty solution that has proven to work is
to reenable the irqs during the function rtl92ce_hw_init().
I think that it is safe doing so since the device interrupt will only be
enabled after the init function succeed.
Signed-off-by: Olivier Langlois oliv
reenable the irqs during the function rtl92ce_hw_init().
I think that it is safe doing so since the device interrupt will only be
enabled after the init function succeed.
Signed-off-by: Olivier Langlois
---
drivers/net/wireless/rtlwifi/ps.c | 2 +-
drivers/net/wireless/rtlwifi/
but a quick and dirty solution that has proven to work is
to reenable the irqs during the function rtl92ce_hw_init().
I think that it is safe doing so since the device interrupt will only be
enabled after the init function succeed.
Signed-off-by: Olivier Langlois oliv...@trillion01.com
() (posix-timers.c)
I believe this misunderstanding may partly explain the current state of
the code.
On Mon, 2013-11-25 at 14:25 -0500, Olivier Langlois wrote:
> When a periodic process timer is fired, a signal is generated.
> Rearming the timer, if necessary, will be performed in a secon
() (posix-timers.c)
I believe this misunderstanding may partly explain the current state of
the code.
On Mon, 2013-11-25 at 14:25 -0500, Olivier Langlois wrote:
When a periodic process timer is fired, a signal is generated.
Rearming the timer, if necessary, will be performed in a second step
919006] cputimer stopped
[ 181.919010] cputimer started
[ 181.920006] cputimer stopped
After:
[ 859.722119] cputimer started
[ 859.730004] cputimer stopped
[ 859.731354] cputimer started
[ 859.739004] cputimer stopped
Signed-off-by: Olivier Langlois
---
kernel/posix-cpu-timers.c | 34 +++
[ 181.919006] cputimer stopped
[ 181.919010] cputimer started
[ 181.920006] cputimer stopped
After:
[ 859.722119] cputimer started
[ 859.730004] cputimer stopped
[ 859.731354] cputimer started
[ 859.739004] cputimer stopped
Signed-off-by: Olivier Langlois oliv...@trillion01.com
---
kernel/posix-cpu
>
> Then please test everything again. I.e.
> o speaker-test -D hdmi:CARD=Generic,DEV=0 -c8 -r192000 -F S32_LE
>
this work fine
> o Is there any difference seen
> with these, in the beginning/end (i.e. fade-out/in):
> speaker-test -D hdmi:CARD=Generic,DEV=0,AES0=0x04 -c2 -r48000
>
Then please test everything again. I.e.
o speaker-test -D hdmi:CARD=Generic,DEV=0 -c8 -r192000 -F S32_LE
this work fine
o Is there any difference seen
with these, in the beginning/end (i.e. fade-out/in):
speaker-test -D hdmi:CARD=Generic,DEV=0,AES0=0x04 -c2 -r48000
> >
> > Rear left and rear right channels are flipped.
>
> Thanks for testing.
>
> That seems a bit strange, I would've expected everything to be flipped
> if there was a bug there.
>
Anssi, you were right to be suspicious. The bug was in my wiring.
>
> >>
> >> o Contents of
Rear left and rear right channels are flipped.
Thanks for testing.
That seems a bit strange, I would've expected everything to be flipped
if there was a bug there.
Anssi, you were right to be suspicious. The bug was in my wiring.
o Contents of /proc/asound/cardX/eld#0. I'd
Anssi,
Your patch has been applied on 3.11.3
>
> I'm especially interested in testers with:
>
> - Older codecs other than 0x1002aa01. My best guess still is that the
> new code works on them as well.
> o On these I'd like to know if multichannel and the new formats
> work, i.e. e.g.
>
Anssi,
Your patch has been applied on 3.11.3
I'm especially interested in testers with:
- Older codecs other than 0x1002aa01. My best guess still is that the
new code works on them as well.
o On these I'd like to know if multichannel and the new formats
work, i.e. e.g.
Frederic,
On Tue, 2013-05-07 at 01:18 +0200, Frederic Weisbecker wrote:
> On Mon, Apr 29, 2013 at 02:04:09PM -0400, Olivier Langlois wrote:
> >
> >
> > Forbids the cputimer to drift ahead of its process clock by
> > blocking its update when a tick occu
>cputimer accounting.
> >
> > This inconsistency makes POSIX timer wake up too early. This patch fixes it.
> >
> > Cc: Thomas Gleixner
> > Cc: Frederic Weisbecker
> > Cc: Ingo Molnar
> > Acked-by: Peter Zijlstra
> > Signed-off-by: Olivier Lan
>
> > Maybe the condition around the posix_cpu_timer_schedule() block inside
> > cpu_timer_fire() could even be a good candidate for 'unlikely'
> > qualifier.
>
> Well, cpu_timer_fire() is probably not a fast path. So helping branch
> prediction there probably won't have much measurable effect
On Mon, 2013-04-29 at 23:17 -0400, kosaki.motoh...@gmail.com wrote:
> From: KOSAKI Motohiro
>
> Currently glibc's rt/tst-cputimer1 testcase is spradically fail because
> a timer created by timer_create() may fire earlier than it's specified.
>
> posix_cpu_timer_set() uses "val" as current time
On Mon, 2013-04-29 at 23:17 -0400, kosaki.motoh...@gmail.com wrote:
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Currently glibc's rt/tst-cputimer1 testcase is spradically fail because
a timer created by timer_create() may fire earlier than it's specified.
posix_cpu_timer_set()
Maybe the condition around the posix_cpu_timer_schedule() block inside
cpu_timer_fire() could even be a good candidate for 'unlikely'
qualifier.
Well, cpu_timer_fire() is probably not a fast path. So helping branch
prediction there probably won't have much measurable effect in
On Mon, 2013-04-29 at 15:09 -0400, KOSAKI Motohiro wrote:
> (4/29/13 2:54 PM), Olivier Langlois wrote:
> > On Mon, 2013-04-29 at 14:31 -0400, KOSAKI Motohiro wrote:
> >> (4/29/13 2:20 PM), Olivier Langlois wrote:
> >>>
> >>>>
> >>>>&
On Mon, 2013-04-29 at 14:31 -0400, KOSAKI Motohiro wrote:
> (4/29/13 2:20 PM), Olivier Langlois wrote:
> >
> >>
> >>>> I'm confused. glibc's rt/tst-cputimer1 doesn't have thread exiting code.
> >>>> I have
> >>>> no seen any iss
>
> >> I'm confused. glibc's rt/tst-cputimer1 doesn't have thread exiting code. I
> >> have
> >> no seen any issue in this accounting.
> >
> > glibc launch a helper thread to receive timer signal and will also
> > create a new thread upon signal reception when a timer is created with
> >
-cputimer1.c
2. There is a race condition hard to fix that the code simply need to
acknowledge
its presence and workaround.
3. Also, cputimer is initialized to the process clock value minus deltas. This
is
required for absolute timers.
Signed-off-by: Olivier Langlois
---
kernel/posix-cpu-timers.c | 91
().
Signed-off-by: Olivier Langlois
---
include/linux/kernel_stat.h | 1 +
include/linux/sched.h | 5 +
kernel/sched/core.c | 22 +
kernel/sched/cputime.c | 47 +++--
4 files changed, 65 insertions(+), 10 deletions
because they are added to the global process stats located
in the signal struct from release_task().
Signed-off-by: Olivier Langlois
---
kernel/sched/fair.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7a33e59..52d7b10
On Mon, 2013-04-29 at 13:10 -0400, Olivier Langlois wrote:
> On Mon, 2013-04-29 at 01:06 -0400, KOSAKI Motohiro wrote:
> > (4/27/13 12:40 AM), Olivier Langlois wrote:
> > >
> > >
> > > Forbids the cputimer to drift ahead of its process clock by
> > >
On Mon, 2013-04-29 at 02:45 +0200, Frederic Weisbecker wrote:
> 2013/4/27 Olivier Langlois :
> >
> >
> > Forbids the cputimer to drift ahead of its process clock by
> > blocking its update when a tick occurs while a autoreaping task
> > is currently in do_exit()
On Mon, 2013-04-29 at 02:25 -0400, KOSAKI Motohiro wrote:
> (4/27/13 12:41 AM), Olivier Langlois wrote:
> >
> >
> > Add thread group delta to cpu timer sample when computing a timer
> > expiration.
> >
> > This is mandatory to make sure that the pos
On Mon, 2013-04-29 at 01:06 -0400, KOSAKI Motohiro wrote:
> (4/27/13 12:40 AM), Olivier Langlois wrote:
> >
> >
> > Forbids the cputimer to drift ahead of its process clock by
> > blocking its update when a tick occurs while a autoreaping task
> > is curren
On Mon, 2013-04-29 at 01:06 -0400, KOSAKI Motohiro wrote:
(4/27/13 12:40 AM), Olivier Langlois wrote:
Forbids the cputimer to drift ahead of its process clock by
blocking its update when a tick occurs while a autoreaping task
is currently in do_exit() between the call to release_task
On Mon, 2013-04-29 at 02:25 -0400, KOSAKI Motohiro wrote:
(4/27/13 12:41 AM), Olivier Langlois wrote:
Add thread group delta to cpu timer sample when computing a timer
expiration.
This is mandatory to make sure that the posix cpu timer does not fire too
soon relative
On Mon, 2013-04-29 at 02:45 +0200, Frederic Weisbecker wrote:
2013/4/27 Olivier Langlois oliv...@trillion01.com:
Forbids the cputimer to drift ahead of its process clock by
blocking its update when a tick occurs while a autoreaping task
is currently in do_exit() between the call
On Mon, 2013-04-29 at 13:10 -0400, Olivier Langlois wrote:
On Mon, 2013-04-29 at 01:06 -0400, KOSAKI Motohiro wrote:
(4/27/13 12:40 AM), Olivier Langlois wrote:
Forbids the cputimer to drift ahead of its process clock by
blocking its update when a tick occurs while a autoreaping
because they are added to the global process stats located
in the signal struct from release_task().
Signed-off-by: Olivier Langlois oliv...@trillion01.com
---
kernel/sched/fair.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
().
Signed-off-by: Olivier Langlois oliv...@trillion01.com
---
include/linux/kernel_stat.h | 1 +
include/linux/sched.h | 5 +
kernel/sched/core.c | 22 +
kernel/sched/cputime.c | 47 +++--
4 files changed, 65 insertions
-cputimer1.c
2. There is a race condition hard to fix that the code simply need to
acknowledge
its presence and workaround.
3. Also, cputimer is initialized to the process clock value minus deltas. This
is
required for absolute timers.
Signed-off-by: Olivier Langlois oliv...@trillion01.com
---
kernel
I'm confused. glibc's rt/tst-cputimer1 doesn't have thread exiting code. I
have
no seen any issue in this accounting.
glibc launch a helper thread to receive timer signal and will also
create a new thread upon signal reception when a timer is created with
sigev_notify =
On Mon, 2013-04-29 at 14:31 -0400, KOSAKI Motohiro wrote:
(4/29/13 2:20 PM), Olivier Langlois wrote:
I'm confused. glibc's rt/tst-cputimer1 doesn't have thread exiting code.
I have
no seen any issue in this accounting.
glibc launch a helper thread to receive timer signal
On Mon, 2013-04-29 at 15:09 -0400, KOSAKI Motohiro wrote:
(4/29/13 2:54 PM), Olivier Langlois wrote:
On Mon, 2013-04-29 at 14:31 -0400, KOSAKI Motohiro wrote:
(4/29/13 2:20 PM), Olivier Langlois wrote:
I'm confused. glibc's rt/tst-cputimer1 doesn't have thread exiting
code. I have
>
>
> 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_e
sequences.
Signed-off-by: Olivier Langlois
---
kernel/posix-cpu-timers.c | 91 +++
1 file changed, 76 insertions(+), 15 deletions(-)
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index 8fd709c..10d28cc 100644
--- a/kernel/posix-cpu-timer
it keep the same
pace than the process clock but in fact, what should be done is to
speed up the process clock by adding the missing stats to it.
Signed-off-by: Olivier Langlois
---
kernel/sched/fair.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c
().
Signed-off-by: Olivier Langlois
---
include/linux/kernel_stat.h | 1 +
include/linux/sched.h | 5 +
kernel/sched/core.c | 22 +
kernel/sched/cputime.c | 47 +++--
4 files changed, 65 insertions(+), 10 deletions
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
> >
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:
> > >
>
>
> IMO, a more likely scenario, posix_cpu_timer_schedule() will be called
> from dequeue_signal() which will be from from a different context than
> the interrupt context.
>
I'll be even more explicit. Inside dequeue_signal(),
do_schedule_next_timer() is called which then call
IMO, a more likely scenario, posix_cpu_timer_schedule() will be called
from dequeue_signal() which will be from from a different context than
the interrupt context.
I'll be even more explicit. Inside dequeue_signal(),
do_schedule_next_timer() is called which then call
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:
https://lkml.org/lkml/2013/4/5
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.
it keep the same
pace than the process clock but in fact, what should be done is to
speed up the process clock by adding the missing stats to it.
Signed-off-by: Olivier Langlois oliv...@trillion01.com
---
kernel/sched/fair.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git
().
Signed-off-by: Olivier Langlois oliv...@trillion01.com
---
include/linux/kernel_stat.h | 1 +
include/linux/sched.h | 5 +
kernel/sched/core.c | 22 +
kernel/sched/cputime.c | 47 +++--
4 files changed, 65 insertions
-off-by: Olivier Langlois oliv...@trillion01.com
---
kernel/posix-cpu-timers.c | 91 +++
1 file changed, 76 insertions(+), 15 deletions(-)
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index 8fd709c..10d28cc 100644
--- a/kernel/posix
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 14:47 +0200, Frederic Weisbecker wrote:
>
> >
> > I might be mistaken but I believe that firing timers are not rescheduled
> > in the current interrupt context. They are going to be rescheduled later
> > from the task context handling the timer generated signal.
>
> No,
On Fri, 2013-04-19 at 14:47 +0200, Frederic Weisbecker wrote:
I might be mistaken but I believe that firing timers are not rescheduled
in the current interrupt context. They are going to be rescheduled later
from the task context handling the timer generated signal.
No, when the
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
Hi Frederic,
> /*
> @@ -1279,6 +1277,7 @@ void run_posix_cpu_timers(struct task_struct *tsk)
> LIST_HEAD(firing);
> struct k_itimer *timer, *next;
> unsigned long flags;
> + struct signal_struct *sig;
>
> BUG_ON(!irqs_disabled());
>
> @@ -1336,6 +1335,10 @@ void
Hi Frederic,
/*
@@ -1279,6 +1277,7 @@ void run_posix_cpu_timers(struct task_struct *tsk)
LIST_HEAD(firing);
struct k_itimer *timer, *next;
unsigned long flags;
+ struct signal_struct *sig;
BUG_ON(!irqs_disabled());
@@ -1336,6 +1335,10 @@ void
complex to achieve.
Signed-off-by: Olivier Langlois
---
kernel/posix-cpu-timers.c | 44 +---
kernel/sched/fair.c | 10 +-
2 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index
complex to achieve.
Signed-off-by: Olivier Langlois oliv...@trillion01.com
---
kernel/posix-cpu-timers.c | 44 +---
kernel/sched/fair.c | 10 +-
2 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/kernel/posix-cpu-timers.c b/kernel
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 t
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 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 gettin
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 gettin
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
-cputimer1 in an infinite loop.
Signed-off-by: Olivier Langlois
---
include/linux/kernel_stat.h | 1 +
include/linux/sched.h | 5 +++
kernel/posix-cpu-timers.c | 93 +
kernel/sched/core.c | 22 +--
kernel/sched/cputime.c
-cputimer1 in an infinite loop.
Signed-off-by: Olivier Langlois oliv...@trillion01.com
---
include/linux/kernel_stat.h | 1 +
include/linux/sched.h | 5 +++
kernel/posix-cpu-timers.c | 93 +
kernel/sched/core.c | 22 +--
kernel
96 matches
Mail list logo
