Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

On Mon, Aug 15, 2016 at 10:58:04AM +0100, Mel Gorman wrote: > On Mon, Aug 15, 2016 at 11:19:01AM +0200, Stanislaw Gruszka wrote: > > > Is this really equivalent though? It updates one task instead of all > > > tasks in the group and there is no guarantee that tsk == current. > > > > Oh, my

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

On Mon, Aug 15, 2016 at 10:58:04AM +0100, Mel Gorman wrote: > On Mon, Aug 15, 2016 at 11:19:01AM +0200, Stanislaw Gruszka wrote: > > > Is this really equivalent though? It updates one task instead of all > > > tasks in the group and there is no guarantee that tsk == current. > > > > Oh, my

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

On Mon, Aug 15, 2016 at 11:19:01AM +0200, Stanislaw Gruszka wrote: > > Is this really equivalent though? It updates one task instead of all > > tasks in the group and there is no guarantee that tsk == current. > > Oh, my intention was to update runtime on current. > Ok, so minimally that would

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

On Mon, Aug 15, 2016 at 11:19:01AM +0200, Stanislaw Gruszka wrote: > > Is this really equivalent though? It updates one task instead of all > > tasks in the group and there is no guarantee that tsk == current. > > Oh, my intention was to update runtime on current. > Ok, so minimally that would

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

2016-08-15 17:21 GMT+08:00 Stanislaw Gruszka : > On Mon, Aug 15, 2016 at 05:13:30PM +0800, Wanpeng Li wrote: >> 2016-08-12 20:10 GMT+08:00 Stanislaw Gruszka : >> > Hi >> > >> > On Wed, Aug 10, 2016 at 01:26:41PM +0200, Ingo Molnar wrote: >> >> Nice

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

2016-08-15 17:21 GMT+08:00 Stanislaw Gruszka : > On Mon, Aug 15, 2016 at 05:13:30PM +0800, Wanpeng Li wrote: >> 2016-08-12 20:10 GMT+08:00 Stanislaw Gruszka : >> > Hi >> > >> > On Wed, Aug 10, 2016 at 01:26:41PM +0200, Ingo Molnar wrote: >> >> Nice detective work! I'm wondering, where do we stand

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

On Mon, Aug 15, 2016 at 05:13:30PM +0800, Wanpeng Li wrote: > 2016-08-12 20:10 GMT+08:00 Stanislaw Gruszka : > > Hi > > > > On Wed, Aug 10, 2016 at 01:26:41PM +0200, Ingo Molnar wrote: > >> Nice detective work! I'm wondering, where do we stand if compared with a > >>

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

On Mon, Aug 15, 2016 at 05:13:30PM +0800, Wanpeng Li wrote: > 2016-08-12 20:10 GMT+08:00 Stanislaw Gruszka : > > Hi > > > > On Wed, Aug 10, 2016 at 01:26:41PM +0200, Ingo Molnar wrote: > >> Nice detective work! I'm wondering, where do we stand if compared with a > >> pre-6e998916dfe3 kernel? > >>

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

On Mon, Aug 15, 2016 at 09:33:49AM +0100, Mel Gorman wrote: > On Mon, Aug 15, 2016 at 09:49:05AM +0200, Giovanni Gherdovich wrote: > > > mmtest benchmark results are below (full compare-kernels.sh output is in > > > attachment): > > > > > > vanila-4.7revertprefetch

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

On Mon, Aug 15, 2016 at 09:33:49AM +0100, Mel Gorman wrote: > On Mon, Aug 15, 2016 at 09:49:05AM +0200, Giovanni Gherdovich wrote: > > > mmtest benchmark results are below (full compare-kernels.sh output is in > > > attachment): > > > > > > vanila-4.7revertprefetch

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

2016-08-12 20:10 GMT+08:00 Stanislaw Gruszka : > Hi > > On Wed, Aug 10, 2016 at 01:26:41PM +0200, Ingo Molnar wrote: >> Nice detective work! I'm wondering, where do we stand if compared with a >> pre-6e998916dfe3 kernel? >> >> I admit this is a difficult question: 6e998916dfe3

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

2016-08-12 20:10 GMT+08:00 Stanislaw Gruszka : > Hi > > On Wed, Aug 10, 2016 at 01:26:41PM +0200, Ingo Molnar wrote: >> Nice detective work! I'm wondering, where do we stand if compared with a >> pre-6e998916dfe3 kernel? >> >> I admit this is a difficult question: 6e998916dfe3 does not revert

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

On Mon, Aug 15, 2016 at 09:49:05AM +0200, Giovanni Gherdovich wrote: > > mmtest benchmark results are below (full compare-kernels.sh output is in > > attachment): > > > > vanila-4.7revertprefetch patch > > 4.74 ( 0.00%)3.04 ( 35.93%)4.09

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

On Mon, Aug 15, 2016 at 09:49:05AM +0200, Giovanni Gherdovich wrote: > > mmtest benchmark results are below (full compare-kernels.sh output is in > > attachment): > > > > vanila-4.7revertprefetch patch > > 4.74 ( 0.00%)3.04 ( 35.93%)4.09

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

Hello Stanislaw, On Fri, 2016-08-12 at 14:10 +0200, Stanislaw Gruszka wrote: > > I measured (partial) revert performance on 4.7 using mmtest instructions > from Giovanni and also tested some other possible fix (draft version): > > diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c >

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

Hello Stanislaw, On Fri, 2016-08-12 at 14:10 +0200, Stanislaw Gruszka wrote: > > I measured (partial) revert performance on 4.7 using mmtest instructions > from Giovanni and also tested some other possible fix (draft version): > > diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c >

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

Hi On Wed, Aug 10, 2016 at 01:26:41PM +0200, Ingo Molnar wrote: > Nice detective work! I'm wondering, where do we stand if compared with a > pre-6e998916dfe3 kernel? > > I admit this is a difficult question: 6e998916dfe3 does not revert cleanly > and I > suspect v3.17 does not run easily on a

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

Hi On Wed, Aug 10, 2016 at 01:26:41PM +0200, Ingo Molnar wrote: > Nice detective work! I'm wondering, where do we stand if compared with a > pre-6e998916dfe3 kernel? > > I admit this is a difficult question: 6e998916dfe3 does not revert cleanly > and I > suspect v3.17 does not run easily on a

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

* Giovanni Gherdovich wrote: > Commit 6e998916dfe3 ("sched/cputime: Fix clock_nanosleep()/clock_gettime() > inconsistency") fixed a problem whereby clock_nanosleep() followed by > clock_gettime() could allow a task to wake early. It addressed the problem > by calling the

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

* Giovanni Gherdovich wrote: > Commit 6e998916dfe3 ("sched/cputime: Fix clock_nanosleep()/clock_gettime() > inconsistency") fixed a problem whereby clock_nanosleep() followed by > clock_gettime() could allow a task to wake early. It addressed the problem > by calling the scheduling classes

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

Hello Ingo, thank you for your reply. Ingo Molnar > Nice detective work! I'm wondering, where do we stand if compared with a > pre-6e998916dfe3 kernel? The data follows. A considerable part of the performance loss is recovered; something is still on the table.

Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime()

Hello Ingo, thank you for your reply. Ingo Molnar > Nice detective work! I'm wondering, where do we stand if compared with a > pre-6e998916dfe3 kernel? The data follows. A considerable part of the performance loss is recovered; something is still on the table. "3.18-pre-bug" is the parent of