On 08/13/2014 02:45 PM, Oleg Nesterov wrote:
> On 08/13, Rik van Riel wrote:
>>
>> On 08/13/2014 02:08 PM, Oleg Nesterov wrote:
>>>
>>> Well, I disagree. This is more complex, and this adds yet another lock
>>> which only protects the stats...
>>
>> The other lock is what can tell us that there is
On 08/13, Rik van Riel wrote:
>
> On 08/13/2014 02:08 PM, Oleg Nesterov wrote:
> >
> > Well, I disagree. This is more complex, and this adds yet another lock
> > which only protects the stats...
>
> The other lock is what can tell us that there is a writer active
> NOW, which may be useful when it
On 08/13/2014 02:08 PM, Oleg Nesterov wrote:
> On 08/13, Rik van Riel wrote:
>>
>> On Wed, 13 Aug 2014 19:22:30 +0200
>> Oleg Nesterov wrote:
>>
>>> On 08/12, Rik van Riel wrote:
Any other ideas?
>>>
>>> To simplify, lets suppose that we only need sum_exec_runtime.
>>>
>>> Perhaps we can
On 08/13, Rik van Riel wrote:
>
> On Wed, 13 Aug 2014 19:22:30 +0200
> Oleg Nesterov wrote:
>
> > On 08/12, Rik van Riel wrote:
> > >
> > > Any other ideas?
> >
> > To simplify, lets suppose that we only need sum_exec_runtime.
> >
> > Perhaps we can do something like this
>
> That would probably w
On Wed, Aug 13, 2014 at 01:50:24PM -0400, Rik van Riel wrote:
> On 08/13/2014 01:40 PM, Peter Zijlstra wrote:
>
> > So the problem with the above is the lack of fwd progress; if
> > there's enough clone()/exit() happening in the thread group (and
> > the more CPUs the more possible), we'll keep re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/13/2014 01:40 PM, Peter Zijlstra wrote:
> So the problem with the above is the lack of fwd progress; if
> there's enough clone()/exit() happening in the thread group (and
> the more CPUs the more possible), we'll keep repeating.
We can fall bac
On Wed, Aug 13, 2014 at 07:22:30PM +0200, Oleg Nesterov wrote:
> On 08/12, Rik van Riel wrote:
> >
> > Any other ideas?
>
> To simplify, lets suppose that we only need sum_exec_runtime.
>
> Perhaps we can do something like this
>
> u64 thread_group_sched_runtime(void)
> {
>
On Wed, 13 Aug 2014 19:22:30 +0200
Oleg Nesterov wrote:
> On 08/12, Rik van Riel wrote:
> >
> > Any other ideas?
>
> To simplify, lets suppose that we only need sum_exec_runtime.
>
> Perhaps we can do something like this
That would probably work, indeed.
However, it turns out that a seqcount
On 08/12, Rik van Riel wrote:
>
> Any other ideas?
To simplify, lets suppose that we only need sum_exec_runtime.
Perhaps we can do something like this
u64 thread_group_sched_runtime(void)
{
struct task_struct *tsk = current;
spinlock_t *siglock = &
On Wed, 2014-08-13 at 15:39 +0200, Peter Zijlstra wrote:
> PROCESS_CPUTIME doesn't need tasklist lock;.
Oops, sorry, didn't notice that that had changed.
(not that it looks less painful, just different flavor of agony)
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
On Wed, Aug 13, 2014 at 09:24:06AM -0400, Rik van Riel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/13/2014 07:11 AM, Peter Zijlstra wrote:
> > On Wed, Aug 13, 2014 at 08:59:50AM +0200, Mike Galbraith wrote:
> >
> >> I was told that clock_gettime(CLOCK_PROCESS_CPUTIME_ID) ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/13/2014 07:11 AM, Peter Zijlstra wrote:
> On Wed, Aug 13, 2014 at 08:59:50AM +0200, Mike Galbraith wrote:
>
>> I was told that clock_gettime(CLOCK_PROCESS_CPUTIME_ID) has
>> scalability issues on BIG boxen
>
>> I'm sure the real clock_gettime()
On Wed, Aug 13, 2014 at 08:59:50AM +0200, Mike Galbraith wrote:
> I was told that clock_gettime(CLOCK_PROCESS_CPUTIME_ID) has scalability
> issues on BIG boxen
> I'm sure the real clock_gettime() using proggy that gummed up a ~1200
> core box for "a while" wasn't the testcase below, which will g
On Tue, 2014-08-12 at 21:12 +0200, Oleg Nesterov wrote:
> On 08/12, Rik van Riel wrote:
> >
> > Back in 2009, Spencer Candland pointed out there is a race with
> > do_sys_times, where multiple threads calling do_sys_times can
> > sometimes get decreasing results.
> >
> > https://lkml.org/lkml/2009
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/12/2014 03:12 PM, Oleg Nesterov wrote:
> Afaics, the problem is that a single thread can observe the
> decreasing (say) sum_exec_runtime if it calls do_sys_times() twice
> without the lock.
>
> This is because it can account the exiting sub-thr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/12/2014 03:12 PM, Oleg Nesterov wrote:
> On 08/12, Rik van Riel wrote:
>>
>> Back in 2009, Spencer Candland pointed out there is a race with
>> do_sys_times, where multiple threads calling do_sys_times can
>> sometimes get decreasing results.
On 08/12, Rik van Riel wrote:
>
> Back in 2009, Spencer Candland pointed out there is a race with
> do_sys_times, where multiple threads calling do_sys_times can
> sometimes get decreasing results.
>
> https://lkml.org/lkml/2009/11/3/522
>
> As a result of that discussion, some of the code in do_sy
Back in 2009, Spencer Candland pointed out there is a race with
do_sys_times, where multiple threads calling do_sys_times can
sometimes get decreasing results.
https://lkml.org/lkml/2009/11/3/522
As a result of that discussion, some of the code in do_sys_times
was moved under a spinlock.
However
18 matches
Mail list logo
