On Fri, May 24, 2013 at 11:40 AM, Christoph Lameter wrote:
> On Fri, 24 May 2013, Peter Zijlstra wrote:
>
>> Patch bc3e53f682 ("mm: distinguish between mlocked and pinned pages")
>> broke RLIMIT_MEMLOCK.
>
> Nope the patch fixed a problem with double accounting.
>
> The problem that we seem to
On Fri, May 24, 2013 at 11:40 AM, Christoph Lameter c...@linux.com wrote:
On Fri, 24 May 2013, Peter Zijlstra wrote:
Patch bc3e53f682 (mm: distinguish between mlocked and pinned pages)
broke RLIMIT_MEMLOCK.
Nope the patch fixed a problem with double accounting.
The problem that we seem to
---
mm/page_alloc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 98cbdf6..23b921f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6140,6 +6140,8 @@ __offline_isolated_pages(unsigned long start_pfn,
unsigned long end_pfn)
(5/25/13 9:23 PM), Wanpeng Li wrote:
Hi KOSAKI,
On Sat, May 25, 2013 at 09:16:24PM -0400, KOSAKI Motohiro wrote:
---
mm/page_alloc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 98cbdf6..23b921f 100644
--- a/mm/page_alloc.c
+++ b/mm
> Instead of reverting and renaming --discard, what about making it accept an
> optional argument, so we could use --discard (to enable all thing and keep
> backward compatibility); --discard=cluster & --discard=batch (or whatever we
> think it should be named). I'll try to sort this approach out
(5/21/13 6:26 AM), Karel Zak wrote:
> On Mon, May 20, 2013 at 09:02:43PM -0400, KOSAKI Motohiro wrote:
>>> - if (fl_discard)
>>> + if (fl_discard) {
>>> flags |= SWAP_FLAG_DISCARD;
>>> + if (fl_discard > 1)
>>> +
(5/21/13 6:26 AM), Karel Zak wrote:
On Mon, May 20, 2013 at 09:02:43PM -0400, KOSAKI Motohiro wrote:
- if (fl_discard)
+ if (fl_discard) {
flags |= SWAP_FLAG_DISCARD;
+ if (fl_discard 1)
+ flags |= SWAP_FLAG_DISCARD_CLUSTER;
This is not enough
Instead of reverting and renaming --discard, what about making it accept an
optional argument, so we could use --discard (to enable all thing and keep
backward compatibility); --discard=cluster --discard=batch (or whatever we
think it should be named). I'll try to sort this approach out if
> +.B "\-c, \-\-cluster\-discard"
> +Swapping will discard clusters of swap pages in between freeing them
> +and re-writing to them, if the swap device supports that. This option
> +also implies the
> +.I \-d, \-\-discard
> +swapon flag.
I'm not sure this is good idea. Why can't we make these
(5/20/13 8:04 PM), Rafael Aquini wrote:
> Intruduce a new flag to make page-cluster fine-grained discards while swapping
> conditional, as they can be considered detrimental to some setups. However,
> keep allowing batched discards at sys_swapon() time, when enabled by the
> system administrator.
(5/20/13 8:04 PM), Rafael Aquini wrote:
Intruduce a new flag to make page-cluster fine-grained discards while swapping
conditional, as they can be considered detrimental to some setups. However,
keep allowing batched discards at sys_swapon() time, when enabled by the
system administrator.
+.B \-c, \-\-cluster\-discard
+Swapping will discard clusters of swap pages in between freeing them
+and re-writing to them, if the swap device supports that. This option
+also implies the
+.I \-d, \-\-discard
+swapon flag.
I'm not sure this is good idea. Why can't we make these flags
> From: Naoya Horiguchi
> Date: Wed, 8 May 2013 11:48:01 -0400
> Subject: [PATCH] ipc/shm.c: don't use auto variable hs in newseg()
>
> This patch fixes "warning: unused variable 'hs'" when !CONFIG_HUGETLB_PAGE
> introduced by commit af73e4d9506d "hugetlbfs: fix mmap failure in unaligned
> size
From: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Date: Wed, 8 May 2013 11:48:01 -0400
Subject: [PATCH] ipc/shm.c: don't use auto variable hs in newseg()
This patch fixes warning: unused variable 'hs' when !CONFIG_HUGETLB_PAGE
introduced by commit af73e4d9506d hugetlbfs: fix mmap failure in
f (addr > va->va_start)
> + else if (addr >= va->va_end)
> n = n->rb_right;
OK. This is natural definition. Looks good.
Acked-by: KOSAKI Motohiro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
)
n = n-rb_right;
OK. This is natural definition. Looks good.
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
> > >
>> > > This inconsistency makes POSIX timer wake up too early. This patch fixes
>> > > it.
>> > >
>> > > Cc: Thomas Gleixner
>> > > Cc: Frederic Weisbecker
>> > > Cc: Ingo Molnar
>> > > Acked-by: Pe
>> @@ -250,8 +250,13 @@ void thread_group_cputimer(struct task_struct *tsk,
>> struct task_cputime *times)
>>* values through the TIMER_ABSTIME flag, therefore we have
>>* to synchronize the timer to the clock every time we start
>>* it.
>> +
@@ -250,8 +250,13 @@ void thread_group_cputimer(struct task_struct *tsk,
struct task_cputime *times)
* values through the TIMER_ABSTIME flag, therefore we have
* to synchronize the timer to the clock every time we start
* it.
+ *
+
: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
When tsk-signal-cputimer-running is 1, signal-cputimer and
tsk-sum_sched_runtime increase at the same pace because update_curr()
increases both accounting.
However, there is one exception. When thread exiting, __exit_signal()
turns
>> Why? The following bug_on inhibit both case.
>
> Yes i get lost on the double negation, but still my patch is correct
> and i am not using gup but follow_hugetlb_page directly and i run into
> the issue. My patch does not change the behavior for current user,
> just fix assumption new user
Why? The following bug_on inhibit both case.
Yes i get lost on the double negation, but still my patch is correct
and i am not using gup but follow_hugetlb_page directly and i run into
the issue. My patch does not change the behavior for current user,
just fix assumption new user might have
On Tue, May 7, 2013 at 8:51 PM, Jerome Glisse wrote:
> On Tue, May 7, 2013 at 8:47 PM, KOSAKI Motohiro
> wrote:
>> On Tue, May 7, 2013 at 6:58 PM, wrote:
>>> From: Jerome Glisse
>>>
>>> Do not increase page count if FOLL_GET is not set. None of the
On Tue, May 7, 2013 at 6:58 PM, wrote:
> From: Jerome Glisse
>
> Do not increase page count if FOLL_GET is not set. None of the
> current user can trigger the issue because none of the current
> user call __get_user_pages with both the pages array ptr non
> NULL and the FOLL_GET flags non set
On Tue, May 7, 2013 at 6:58 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
Do not increase page count if FOLL_GET is not set. None of the
current user can trigger the issue because none of the current
user call __get_user_pages with both the pages array ptr non
NULL
On Tue, May 7, 2013 at 8:51 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Tue, May 7, 2013 at 8:47 PM, KOSAKI Motohiro
kosaki.motoh...@gmail.com wrote:
On Tue, May 7, 2013 at 6:58 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
Do not increase page count if FOLL_GET
>> + /*
>> + * After turning over se.sum_exec_runtime to sig->sum_sched_runtime
>> + * in __exit_signal(), we must not account exec_runtime for
>> consistency.
>> + */
>> + if (unlikely(!tsk->sighand))
>> + return;
>
> Ok, if we want the clock and timer to be
From: KOSAKI Motohiro
Currently glibc rt/tst-cpuclock2 test(*) sporadically fails because
scheduler delta can be accounted twice from thread_group_cputimer()
and account_group_exec_runtime().
Finally, clock_nanosleep() wakes up before an argument. This is posix
violation. This issue
From: KOSAKI Motohiro
rq lock in task_sched_runtime() is necessary for two reasons. 1)
accessing se.sum_exec_runtime is not atomic on 32bit and 2)
do_task_delta_exec() require it.
So, 64bit can avoid holding rq lock when add_delta is false and
delta_exec is 0.
Cc: Olivier Langlois
Cc: Thomas
From: KOSAKI Motohiro
Now we have four similar timer related functions, cpu_clock_sample(),
cpu_clock_sample_group(), cpu_timer_sample() and cpu_timer_sample_group().
For readability, make do_cpu_clock_timer_sample() and thread_cputime()
helper functions and all *_sample functions use
From: KOSAKI Motohiro
A type of tsk->se.sum_exec_runtime is u64. Thus, reading it is racy when
running 32bit. We should use task_sched_runtime().
Cc: Olivier Langlois
Cc: Thomas Gleixner
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Acked-by: Peter Zijlstra
Signed-off-by: KOSAKI Motoh
From: KOSAKI Motohiro
Currently glibc's rt/tst-cputimer1 testcase sporadically fails because
a timer created by timer_create() may fire earlier than specified.
posix_cpu_timer_set() uses "val" as current time for three purpose. 1)
initialize sig->cputimer. 2) calculation
From: KOSAKI Motohiro
For process timers, we use cpu_clock_sample_group() and cpu_timer_sample_group()
correctly. However, for thread timers, we always use cpu_clock_sample(). This is
wrong because a cpu_clock_sample() accounts uncommitted delta_exec too. And this
is inconsistent against
From: KOSAKI Motohiro
When tsk->signal->cputimer->running is 1, signal->cputimer and
tsk->sum_sched_runtime increase at the same pace because update_curr()
increases both accounting.
However, there is one exception. When thread exiting, __exit_signal() turns
over task's sum_shced
From: KOSAKI Motohiro
Glibc's posix timer testcase found a lot of bugs in posix timer code.
This series, hopefully, fixes all of them. All patches are independent
each other logically.
Changes from v3
- task_sched_runtime() micro optimization add to care tsk->on_cpu.
suggested Paul Tur
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Glibc's posix timer testcase found a lot of bugs in posix timer code.
This series, hopefully, fixes all of them. All patches are independent
each other logically.
Changes from v3
- task_sched_runtime() micro optimization add to care tsk
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
When tsk-signal-cputimer-running is 1, signal-cputimer and
tsk-sum_sched_runtime increase at the same pace because update_curr()
increases both accounting.
However, there is one exception. When thread exiting, __exit_signal() turns
over task's
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Currently glibc's rt/tst-cputimer1 testcase sporadically fails because
a timer created by timer_create() may fire earlier than specified.
posix_cpu_timer_set() uses val as current time for three purpose. 1)
initialize sig-cputimer. 2
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
For process timers, we use cpu_clock_sample_group() and cpu_timer_sample_group()
correctly. However, for thread timers, we always use cpu_clock_sample(). This is
wrong because a cpu_clock_sample() accounts uncommitted delta_exec too
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
A type of tsk-se.sum_exec_runtime is u64. Thus, reading it is racy when
running 32bit. We should use task_sched_runtime().
Cc: Olivier Langlois oliv...@trillion01.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Frederic Weisbecker fweis
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
rq lock in task_sched_runtime() is necessary for two reasons. 1)
accessing se.sum_exec_runtime is not atomic on 32bit and 2)
do_task_delta_exec() require it.
So, 64bit can avoid holding rq lock when add_delta is false and
delta_exec is 0.
Cc
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Now we have four similar timer related functions, cpu_clock_sample(),
cpu_clock_sample_group(), cpu_timer_sample() and cpu_timer_sample_group().
For readability, make do_cpu_clock_timer_sample() and thread_cputime()
helper functions and all
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Currently glibc rt/tst-cpuclock2 test(*) sporadically fails because
scheduler delta can be accounted twice from thread_group_cputimer()
and account_group_exec_runtime().
Finally, clock_nanosleep() wakes up before an argument. This is posix
> Stronger:
>
> +#ifdef CONFIG_64BIT
> + if (!p->on_cpu)
> + return p->se.sum_exec_runtime;
> +#endif
>
> [ Or !p->on_cpu || !add_delta ].
>
> We can take the racy read versus p->on_cpu since:
> If we race with it leaving cpu: we take lock, we're correct
> If we race
(5/1/13 7:01 AM), Peter Zijlstra wrote:
> On Mon, Apr 29, 2013 at 11:17:08PM -0400, kosaki.motoh...@gmail.com wrote:
>> Glibc's posix timer testcase found a lot of bugs in posix timer code. This
>> series, hopefully,
>> fixes all of them. All patches are independent each other logically.
>>
>>
>>
(5/1/13 7:00 AM), Peter Zijlstra wrote:
> On Mon, Apr 29, 2013 at 11:17:17PM -0400, kosaki.motoh...@gmail.com wrote:
>> From: KOSAKI Motohiro
>>
>> rq lock in task_sched_runtime() is necessary for two reasons. 1)
>> accessing se.sum_exec_runtime is inatomic on 32bit a
(5/1/13 7:00 AM), Peter Zijlstra wrote:
On Mon, Apr 29, 2013 at 11:17:17PM -0400, kosaki.motoh...@gmail.com wrote:
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
rq lock in task_sched_runtime() is necessary for two reasons. 1)
accessing se.sum_exec_runtime is inatomic on 32bit and 2
(5/1/13 7:01 AM), Peter Zijlstra wrote:
On Mon, Apr 29, 2013 at 11:17:08PM -0400, kosaki.motoh...@gmail.com wrote:
Glibc's posix timer testcase found a lot of bugs in posix timer code. This
series, hopefully,
fixes all of them. All patches are independent each other logically.
[PATCH 1/7]
Stronger:
+#ifdef CONFIG_64BIT
+ if (!p-on_cpu)
+ return p-se.sum_exec_runtime;
+#endif
[ Or !p-on_cpu || !add_delta ].
We can take the racy read versus p-on_cpu since:
If we race with it leaving cpu: we take lock, we're correct
If we race with it entering
Hm. I'm not sure why this path series start [patch 4/10]. maybe I need to
review my script again.
anyway, patch 1-3 don't exist. sorry for confusing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
From: Kishon Vijay Abraham I
Commit 92702df3570e ("ARM: OMAP4: PM: fix PM regression introduced by recent
clock cleanup") makes the 'ocp2scp_usb_phy_phy_48m' as optional
functional clock causing regression in MUSB. But this 48MHz clock is a
mandatory clock for usb phy attached to ocp2scp and
From: KOSAKI Motohiro
Now we have similar four timer related functions, cpu_clock_sample(),
cpu_clock_sample_group(), cpu_timer_sample() and cpu_timer_sample_group().
For readability, making do_cpu_clock_timer_sample() and thread_cputime()
helper functions and all *_sample functions use them
From: KOSAKI Motohiro
rq lock in task_sched_runtime() is necessary for two reasons. 1)
accessing se.sum_exec_runtime is inatomic on 32bit and 2)
do_task_delta_exec() require it.
And then, 64bit can avoid holds rq lock when add_delta is false.
Signed-off-by: KOSAKI Motohiro
---
kernel/sched
From: KOSAKI Motohiro
A type of tsk->se.sum_exec_runtime is u64. Thus reading it is racy when
running 32bit. We should use task_sched_runtime().
Cc: Olivier Langlois
CC: Martin Schwidefsky
Cc: Steven Rostedt
Cc: Thomas Gleixner
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Peter Zijls
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 for three purpose. 1)
initialize sig->cputimer. 2) calculation
From: KOSAKI Motohiro
For process timer, we use cpu_clock_sample_group() and cpu_timer_sample_group()
correctly. However for thread timer, we always use cpu_clock_sample().
That's wrong becuase cpu_clock_sample() account uncommited delta_exec too. And
this is inconsistency against
From: KOSAKI Motohiro
Currently glibc rt/tst-cpuclock2 test(*) sporadically fail. Because
scheduler delta can be accounted twice from thread_group_cputimer()
and account_group_exec_runtime().
Finally, clock_nanosleep() wakes up before an argument. And that is
posix violation. This issue
From: KOSAKI Motohiro
When tsk->signal->cputimer->running is 1, signal->cputimer and
tsk->sum_sched_runtime increase the same pace. update_curr() increase
both account.
However, there is one exeception. When thread exiting, __exit_signal()
turns over task's sum_shced
From: Paul E. McKenney
The following RCU splat indicates lack of RCU protection:
[ 953.267649] ===
[ 953.267652] [ INFO: suspicious RCU usage. ]
[ 953.267657] 3.9.0-0.rc6.git2.4.fc19.ppc64p7 #1 Not tainted
[ 953.267661] ---
[
From: Linus Torvalds
I think we could just move the full vm_iomap_memory() function into
util.h or similar, but I didn't get any reply from anybody actually
using nommu even to this trivial patch, so I'm not going to touch it any
more than required.
Here's the fairly minimal stub to make the
Glibc's posix timer testcase found a lot of bugs in posix timer code. This
series, hopefully,
fixes all of them. All patches are independent each other logically.
[PATCH 1/7] posix-cpu-timers: don't account cpu timer after stopped thread
runtime accounting
[PATCH 2/7] posix-cpu-timers: fix
>> tick lost doesn't occur an issue. because glibc only test posix conformance
>> and
>> posix allow inacculacy. In other words, timer must not run faster than real
>> clock.
>> but lost and makes slower are accepted in the test.
>>
> What is lost isn't cputimer tick. They are accounted
>
(4/22/13 11:23 AM), vinayakm.l...@gmail.com wrote:
> From: Vinayak Menon
>
> There are times when HIGHMEM is enabled, but
> we don't prefer CONFIG_BOUNCE to be enabled.
> CONFIG_BOUNCE can reduce the block device
> throughput, and this is not ideal for machines
> where we don't gain much by
. Say it's just about to expire.
*/
itp->it_value.tv_nsec = 1;
itp->it_value.tv_sec = 0;
Signed-off-by: KOSAKI Motohiro
---
kernel/posix-cpu-timers.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-ti
Zijlstra
Signed-off-by: KOSAKI Motohiro
---
include/linux/sched.h |1 +
kernel/posix-cpu-timers.c | 123 +
kernel/sched/cputime.c| 11
3 files changed, 70 insertions(+), 65 deletions(-)
diff --git a/include/linux/sched.h b/include/linux
rq lock in task_sched_runtime() is necessary for two reasons. 1)
accessing se.sum_exec_runtime is inatomic on 32bit and 2)
do_task_delta_exec() require it.
And then, 64bit can avoid holds rq lock when add_delta is false.
Signed-off-by: KOSAKI Motohiro
---
kernel/sched/core.c |6 ++
1
A type of tsk->se.sum_exec_runtime is u64. Thus reading it is racy when
running 32bit. We should use task_sched_runtime().
Cc: Olivier Langlois
CC: Martin Schwidefsky
Cc: Steven Rostedt
Cc: Thomas Gleixner
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Peter Zijlstra
Signed-off-by: KOS
(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.
>>&
>>> @@ -749,7 +756,13 @@ static int posix_cpu_timer_set(struct k_itimer *timer,
>>> int flags,
>>> }
>>>
>>> if (new_expires.sched != 0 && !(flags & TIMER_ABSTIME)) {
>>> - cpu_time_add(timer->it_clock, _expires, val);
>>> + union cpu_time_count now;
>>> +
>>> +
(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 and will also
>>> create a new thread upon signal
(4/29/13 1:10 PM), 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 updat
(4/29/13 6:36 AM), Peter Zijlstra wrote:
> On Mon, Apr 29, 2013 at 02:26:02AM -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 fai
From: KOSAKI Motohiro
Currently glibc rt/tst-cpuclock2 test(*) sporadically fail. Because
scheduler delta can be accounted twice from thread_group_cputimer()
and account_group_exec_runtime().
Finally, clock_nanosleep() wakes up before an argument. And that is
posix violation. This issue
From: KOSAKI Motohiro
Currently glibc's rt/tst-cputimer1 testcase is spradically fail because
a timer created by timer_create() may faire earlier than an argument.
There are two faults. 1) cpu_timer_sample_group() adds task_delta_exec(current).
But it is definity silly idea especially when
(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 to the process cpu clock which do include the task group delta.
>
> test
(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 to the process cpu clock which do include the task group delta.
test case to
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Currently glibc rt/tst-cpuclock2 test(*) sporadically fail. Because
scheduler delta can be accounted twice from thread_group_cputimer()
and account_group_exec_runtime().
Finally, clock_nanosleep() wakes up before an argument. And that is
posix
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 faire earlier than an argument.
There are two faults. 1) cpu_timer_sample_group() adds task_delta_exec(current).
But it is definity
(4/29/13 6:36 AM), Peter Zijlstra wrote:
On Mon, Apr 29, 2013 at 02:26:02AM -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 faire earlier
(4/29/13 1:10 PM), 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 task
is currently
(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 and will also
create a new thread upon signal reception when a timer is
@@ -749,7 +756,13 @@ static int posix_cpu_timer_set(struct k_itimer *timer,
int flags,
}
if (new_expires.sched != 0 !(flags TIMER_ABSTIME)) {
- cpu_time_add(timer-it_clock, new_expires, val);
+ union cpu_time_count now;
+
+ if
(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
no seen any issue in this accounting.
glibc launch a helper
: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Signed-off-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
---
kernel/posix-cpu-timers.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kernel/posix-cpu
rq lock in task_sched_runtime() is necessary for two reasons. 1)
accessing se.sum_exec_runtime is inatomic on 32bit and 2)
do_task_delta_exec() require it.
And then, 64bit can avoid holds rq lock when add_delta is false.
Signed-off-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
---
kernel
Zijlstra pet...@infradead.org
Signed-off-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
---
include/linux/sched.h |1 +
kernel/posix-cpu-timers.c | 123 +
kernel/sched/cputime.c| 11
3 files changed, 70 insertions(+), 65 deletions
it's just about to expire.
*/
itp-it_value.tv_nsec = 1;
itp-it_value.tv_sec = 0;
Signed-off-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
---
kernel/posix-cpu-timers.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/posix-cpu-timers.c b/kernel
(4/22/13 11:23 AM), vinayakm.l...@gmail.com wrote:
From: Vinayak Menon vinayakm.l...@gmail.com
There are times when HIGHMEM is enabled, but
we don't prefer CONFIG_BOUNCE to be enabled.
CONFIG_BOUNCE can reduce the block device
throughput, and this is not ideal for machines
where we don't
tick lost doesn't occur an issue. because glibc only test posix conformance
and
posix allow inacculacy. In other words, timer must not run faster than real
clock.
but lost and makes slower are accepted in the test.
What is lost isn't cputimer tick. They are accounted
Glibc's posix timer testcase found a lot of bugs in posix timer code. This
series, hopefully,
fixes all of them. All patches are independent each other logically.
[PATCH 1/7] posix-cpu-timers: don't account cpu timer after stopped thread
runtime accounting
[PATCH 2/7] posix-cpu-timers: fix
From: Linus Torvalds torva...@linux-foundation.org
I think we could just move the full vm_iomap_memory() function into
util.h or similar, but I didn't get any reply from anybody actually
using nommu even to this trivial patch, so I'm not going to touch it any
more than required.
Here's the
From: Paul E. McKenney paul...@linux.vnet.ibm.com
The following RCU splat indicates lack of RCU protection:
[ 953.267649] ===
[ 953.267652] [ INFO: suspicious RCU usage. ]
[ 953.267657] 3.9.0-0.rc6.git2.4.fc19.ppc64p7 #1 Not tainted
[ 953.267661]
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
When tsk-signal-cputimer-running is 1, signal-cputimer and
tsk-sum_sched_runtime increase the same pace. update_curr() increase
both account.
However, there is one exeception. When thread exiting, __exit_signal()
turns over task's
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Currently glibc rt/tst-cpuclock2 test(*) sporadically fail. Because
scheduler delta can be accounted twice from thread_group_cputimer()
and account_group_exec_runtime().
Finally, clock_nanosleep() wakes up before an argument. And that is
posix
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() uses val as current time for three purpose. 1)
initialize sig-cputimer. 2
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
For process timer, we use cpu_clock_sample_group() and cpu_timer_sample_group()
correctly. However for thread timer, we always use cpu_clock_sample().
That's wrong becuase cpu_clock_sample() account uncommited delta_exec too
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
A type of tsk-se.sum_exec_runtime is u64. Thus reading it is racy when
running 32bit. We should use task_sched_runtime().
Cc: Olivier Langlois oliv...@trillion01.com
CC: Martin Schwidefsky schwidef...@de.ibm.com
Cc: Steven Rostedt rost
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
rq lock in task_sched_runtime() is necessary for two reasons. 1)
accessing se.sum_exec_runtime is inatomic on 32bit and 2)
do_task_delta_exec() require it.
And then, 64bit can avoid holds rq lock when add_delta is false.
Signed-off-by: KOSAKI
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Now we have similar four timer related functions, cpu_clock_sample(),
cpu_clock_sample_group(), cpu_timer_sample() and cpu_timer_sample_group().
For readability, making do_cpu_clock_timer_sample() and thread_cputime()
helper functions and all
From: Kishon Vijay Abraham I kis...@ti.com
Commit 92702df3570e (ARM: OMAP4: PM: fix PM regression introduced by recent
clock cleanup) makes the 'ocp2scp_usb_phy_phy_48m' as optional
functional clock causing regression in MUSB. But this 48MHz clock is a
mandatory clock for usb phy attached to
301 - 400 of 949 matches
Mail list logo
