[tip: sched/core] sched/fair: Eliminate bandwidth race between throttling and distribution

The following commit has been merged into the sched/core branch of tip: Commit-ID: e98fa02c4f2ea4991dae422ac7e34d102d2f0599 Gitweb: https://git.kernel.org/tip/e98fa02c4f2ea4991dae422ac7e34d102d2f0599 Author:Paul Turner AuthorDate:Fri, 10 Apr 2020 15:52:07 -07:00 Committer

Re: [RFC] x86: Speculative execution warnings

From: Nadav Amit Date: Fri, May 10, 2019 at 7:45 PM To: Cc: Borislav Petkov, , Nadav Amit, Andy Lutomirsky, Ingo Molnar, Peter Zijlstra, Thomas Gleixner, Jann Horn > It may be useful to check in runtime whether certain assertions are > violated even during speculative execution. This can allow

Re: [PATCH] x86/retpoline: Avoid return buffer underflows on context switch

On Mon, Jan 8, 2018 at 4:48 PM, David Woodhouse wrote: > On Tue, 2018-01-09 at 00:44 +, Woodhouse, David wrote: >> On IRC, Arjan assures me that 'pause' here really is sufficient as a >> speculation trap. If we do end up returning back here as a >> misprediction, that

Re: [PATCH] x86/retpoline: Avoid return buffer underflows on context switch

On Mon, Jan 8, 2018 at 4:48 PM, David Woodhouse wrote: > On Tue, 2018-01-09 at 00:44 +, Woodhouse, David wrote: >> On IRC, Arjan assures me that 'pause' here really is sufficient as a >> speculation trap. If we do end up returning back here as a >> misprediction, that 'pause' will stop the

Re: [PATCH v6 11/10] x86/retpoline: Avoid return buffer underflows on context switch II

On Mon, Jan 8, 2018 at 5:21 PM, Andi Kleen wrote: > On Mon, Jan 08, 2018 at 05:16:02PM -0800, Andi Kleen wrote: >> > If we clear the registers, what the hell are you going to put in the >> > RSB that helps you? >> >> RSB allows you to control chains of gadgets. > > I admit

Re: [PATCH v6 11/10] x86/retpoline: Avoid return buffer underflows on context switch II

On Mon, Jan 8, 2018 at 5:21 PM, Andi Kleen wrote: > On Mon, Jan 08, 2018 at 05:16:02PM -0800, Andi Kleen wrote: >> > If we clear the registers, what the hell are you going to put in the >> > RSB that helps you? >> >> RSB allows you to control chains of gadgets. > > I admit the gadget thing is a

Re: [PATCH] x86/retpoline: Avoid return buffer underflows on context switch

On Mon, Jan 8, 2018 at 2:25 PM, Andi Kleen wrote: >> So pjt did alignment, a single unroll and per discussion earlier today >> (CET) or late last night (PST), he only does 16. > > I used the Intel recommended sequence, which recommends 32. > > Not sure if alignment makes a

Re: [PATCH] x86/retpoline: Avoid return buffer underflows on context switch

On Mon, Jan 8, 2018 at 2:25 PM, Andi Kleen wrote: >> So pjt did alignment, a single unroll and per discussion earlier today >> (CET) or late last night (PST), he only does 16. > > I used the Intel recommended sequence, which recommends 32. > > Not sure if alignment makes a difference. I can

Re: [PATCH] x86/retpoline: Avoid return buffer underflows on context switch

On Mon, Jan 8, 2018 at 2:11 PM, Peter Zijlstra wrote: > On Mon, Jan 08, 2018 at 12:15:31PM -0800, Andi Kleen wrote: >> diff --git a/arch/x86/include/asm/nospec-branch.h >> b/arch/x86/include/asm/nospec-branch.h >> index b8c8eeacb4be..e84e231248c2 100644 >> ---

Re: [PATCH] x86/retpoline: Avoid return buffer underflows on context switch

On Mon, Jan 8, 2018 at 2:11 PM, Peter Zijlstra wrote: > On Mon, Jan 08, 2018 at 12:15:31PM -0800, Andi Kleen wrote: >> diff --git a/arch/x86/include/asm/nospec-branch.h >> b/arch/x86/include/asm/nospec-branch.h >> index b8c8eeacb4be..e84e231248c2 100644 >> ---

Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel

a binary, or a new AMD processor, 32 calls are required. I would suggest tuning this based on the current CPU (which also covers the future case while saving cycles now) to save overhead. On Mon, Jan 8, 2018 at 3:16 AM, Andrew Cooper <andrew.coop...@citrix.com> wrote: > On 08/01/18 10:42, Pa

Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel

a binary, or a new AMD processor, 32 calls are required. I would suggest tuning this based on the current CPU (which also covers the future case while saving cycles now) to save overhead. On Mon, Jan 8, 2018 at 3:16 AM, Andrew Cooper wrote: > On 08/01/18 10:42, Paul Turner wrote: >> A

Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel

On Mon, Jan 8, 2018 at 2:45 AM, David Woodhouse <dw...@infradead.org> wrote: > On Mon, 2018-01-08 at 02:34 -0800, Paul Turner wrote: >> One detail that is missing is that we still need RSB refill in some >> cases. >> This is not because the retpoline seq

Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel

On Mon, Jan 8, 2018 at 2:45 AM, David Woodhouse wrote: > On Mon, 2018-01-08 at 02:34 -0800, Paul Turner wrote: >> One detail that is missing is that we still need RSB refill in some >> cases. >> This is not because the retpoline sequence itself will underflow (it >

Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel

On Mon, Jan 8, 2018 at 2:38 AM, Jiri Kosina <ji...@kernel.org> wrote: > On Mon, 8 Jan 2018, Paul Turner wrote: > >> user->kernel in the absence of SMEP: >> In the absence of SMEP, we must worry about user-generated RSB entries >> being consumable by kernel

Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel

On Mon, Jan 8, 2018 at 2:38 AM, Jiri Kosina wrote: > On Mon, 8 Jan 2018, Paul Turner wrote: > >> user->kernel in the absence of SMEP: >> In the absence of SMEP, we must worry about user-generated RSB entries >> being consumable by kernel execution. >> Generally sp

Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel

k ~43 cycles on average. Note that non-zero displacement calls should be used as these may be optimized to not interact with the RSB due to their use in fetching RIP for 32-bit relocations. On Mon, Jan 8, 2018 at 2:34 AM, Paul Turner <p...@google.com> wrote: > One detail that is missing i

Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel

k ~43 cycles on average. Note that non-zero displacement calls should be used as these may be optimized to not interact with the RSB due to their use in fetching RIP for 32-bit relocations. On Mon, Jan 8, 2018 at 2:34 AM, Paul Turner wrote: > One detail that is missing is that we st

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 5, 2018 at 3:26 AM, Paolo Bonzini <pbonz...@redhat.com> wrote: > On 05/01/2018 11:28, Paul Turner wrote: >> >> The "pause; jmp" sequence proved minutely faster than "lfence;jmp" which is >> why >> it was chosen. >> >>

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 5, 2018 at 3:26 AM, Paolo Bonzini wrote: > On 05/01/2018 11:28, Paul Turner wrote: >> >> The "pause; jmp" sequence proved minutely faster than "lfence;jmp" which is >> why >> it was chosen. >> >> "pause; jmp" 3

Re: [PATCH 0/7] IBRS patch series

On Fri, Jan 5, 2018 at 3:32 AM, Paolo Bonzini wrote: > On 04/01/2018 22:22, Van De Ven, Arjan wrote: >> this is about a level of paranoia you are comfortable with. >> >> Retpoline on Skylake raises the bar for the issue enormously, but >> there are a set of corner cases that

Re: [PATCH 0/7] IBRS patch series

On Fri, Jan 5, 2018 at 3:32 AM, Paolo Bonzini wrote: > On 04/01/2018 22:22, Van De Ven, Arjan wrote: >> this is about a level of paranoia you are comfortable with. >> >> Retpoline on Skylake raises the bar for the issue enormously, but >> there are a set of corner cases that exist and that are

Re: [PATCH 0/7] IBRS patch series

On Thu, Jan 4, 2018 at 11:33 AM, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse wrote: >> >> On Skylake the target for a 'ret' instruction may also come from the >> BTB. So if you ever let the RSB (which remembers

Re: [PATCH 0/7] IBRS patch series

On Thu, Jan 4, 2018 at 11:33 AM, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse wrote: >> >> On Skylake the target for a 'ret' instruction may also come from the >> BTB. So if you ever let the RSB (which remembers where the 'call's came >> from get empty, you end up

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 05, 2018 at 10:55:38AM +, David Woodhouse wrote: > On Fri, 2018-01-05 at 02:28 -0800, Paul Turner wrote: > > On Thu, Jan 04, 2018 at 07:27:58PM +, David Woodhouse wrote: > > > On Thu, 2018-01-04 at 10:36 -0800, Alexei Starovoitov wrote: > >

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 05, 2018 at 10:55:38AM +, David Woodhouse wrote: > On Fri, 2018-01-05 at 02:28 -0800, Paul Turner wrote: > > On Thu, Jan 04, 2018 at 07:27:58PM +, David Woodhouse wrote: > > > On Thu, 2018-01-04 at 10:36 -0800, Alexei Starovoitov wrote: > >

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 05, 2018 at 10:55:38AM +, David Woodhouse wrote: > On Fri, 2018-01-05 at 02:28 -0800, Paul Turner wrote: > > On Thu, Jan 04, 2018 at 07:27:58PM +, David Woodhouse wrote: > > > On Thu, 2018-01-04 at 10:36 -0800, Alexei Starovoitov wrote: > >

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 05, 2018 at 10:55:38AM +, David Woodhouse wrote: > On Fri, 2018-01-05 at 02:28 -0800, Paul Turner wrote: > > On Thu, Jan 04, 2018 at 07:27:58PM +, David Woodhouse wrote: > > > On Thu, 2018-01-04 at 10:36 -0800, Alexei Starovoitov wrote: > >

Re: [RFC] Retpoline: Binary mitigation for branch-target-injection (aka "Spectre")

On Thu, Jan 04, 2018 at 08:18:57AM -0800, Andy Lutomirski wrote: > On Thu, Jan 4, 2018 at 1:30 AM, Woodhouse, David <d...@amazon.co.uk> wrote: > > On Thu, 2018-01-04 at 01:10 -0800, Paul Turner wrote: > >> Apologies for the discombobulation around today'

Re: [RFC] Retpoline: Binary mitigation for branch-target-injection (aka "Spectre")

On Thu, Jan 04, 2018 at 08:18:57AM -0800, Andy Lutomirski wrote: > On Thu, Jan 4, 2018 at 1:30 AM, Woodhouse, David wrote: > > On Thu, 2018-01-04 at 01:10 -0800, Paul Turner wrote: > >> Apologies for the discombobulation around today's disclosure. Obviously > >

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Thu, Jan 04, 2018 at 10:25:35AM -0800, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 10:17 AM, Alexei Starovoitov > wrote: > > > > Clearly Paul's approach to retpoline without lfence is faster. Using pause rather than lfence does not represent a fundamental

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Thu, Jan 04, 2018 at 10:25:35AM -0800, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 10:17 AM, Alexei Starovoitov > wrote: > > > > Clearly Paul's approach to retpoline without lfence is faster. Using pause rather than lfence does not represent a fundamental difference here. A protected

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Thu, Jan 04, 2018 at 10:40:23AM -0800, Andi Kleen wrote: > > Clearly Paul's approach to retpoline without lfence is faster. > > I'm guessing it wasn't shared with amazon/intel until now and > > this set of patches going to adopt it, right? > > > > Paul, could you share a link to a set of

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Thu, Jan 04, 2018 at 10:40:23AM -0800, Andi Kleen wrote: > > Clearly Paul's approach to retpoline without lfence is faster. > > I'm guessing it wasn't shared with amazon/intel until now and > > this set of patches going to adopt it, right? > > > > Paul, could you share a link to a set of

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Thu, Jan 04, 2018 at 07:27:58PM +, David Woodhouse wrote: > On Thu, 2018-01-04 at 10:36 -0800, Alexei Starovoitov wrote: > > > > Pretty much. > > Paul's writeup: https://support.google.com/faqs/answer/7625886 > > tldr: jmp *%r11 gets converted to: > > call set_up_target; > > capture_spec:

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Thu, Jan 04, 2018 at 07:27:58PM +, David Woodhouse wrote: > On Thu, 2018-01-04 at 10:36 -0800, Alexei Starovoitov wrote: > > > > Pretty much. > > Paul's writeup: https://support.google.com/faqs/answer/7625886 > > tldr: jmp *%r11 gets converted to: > > call set_up_target; > > capture_spec:

Re: [RFC] Retpoline: Binary mitigation for branch-target-injection (aka "Spectre")

On Thu, Jan 4, 2018 at 1:10 AM, Paul Turner <p...@google.com> wrote: > Apologies for the discombobulation around today's disclosure. Obviously the > original goal was to communicate this a little more coherently, but the > unscheduled advances in the disclosure disrupted the

Re: [RFC] Retpoline: Binary mitigation for branch-target-injection (aka "Spectre")

On Thu, Jan 4, 2018 at 1:10 AM, Paul Turner wrote: > Apologies for the discombobulation around today's disclosure. Obviously the > original goal was to communicate this a little more coherently, but the > unscheduled advances in the disclosure disrupted the efforts to pull this > t

Re: [RFC] Retpoline: Binary mitigation for branch-target-injection (aka "Spectre")

On Thu, Jan 4, 2018 at 1:10 AM, Paul Turner <p...@google.com> wrote: > Apologies for the discombobulation around today's disclosure. Obviously the > original goal was to communicate this a little more coherently, but the > unscheduled advances in the disclosure disrupted the

Re: [RFC] Retpoline: Binary mitigation for branch-target-injection (aka "Spectre")

On Thu, Jan 4, 2018 at 1:10 AM, Paul Turner wrote: > Apologies for the discombobulation around today's disclosure. Obviously the > original goal was to communicate this a little more coherently, but the > unscheduled advances in the disclosure disrupted the efforts to pull this > t

[RFC] Retpoline: Binary mitigation for branch-target-injection (aka "Spectre")

Apologies for the discombobulation around today's disclosure. Obviously the original goal was to communicate this a little more coherently, but the unscheduled advances in the disclosure disrupted the efforts to pull this together more cleanly. I wanted to open discussion the "retpoline"

[RFC] Retpoline: Binary mitigation for branch-target-injection (aka "Spectre")

Apologies for the discombobulation around today's disclosure. Obviously the original goal was to communicate this a little more coherently, but the unscheduled advances in the disclosure disrupted the efforts to pull this together more cleanly. I wanted to open discussion the "retpoline"

Re: Avoid speculative indirect calls in kernel

On Wed, Jan 3, 2018 at 3:51 PM, Linus Torvalds wrote: > On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen wrote: >> This is a fix for Variant 2 in >> https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html >> >> Any

Re: Avoid speculative indirect calls in kernel

On Wed, Jan 3, 2018 at 3:51 PM, Linus Torvalds wrote: > On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen wrote: >> This is a fix for Variant 2 in >> https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html >> >> Any speculative indirect calls in the kernel can be tricked

Re: [RFC PATCH for 4.15 00/24] Restartable sequences and CPU op vector v11

I have some comments that apply to many of the threads. I've been fully occupied with a wedding and a security issue; but I'm about to be free to spend the majority of my time on RSEQ things. I was sorely hoping that day would be today. But it's looking like I'm still a day or two from being free

Re: [RFC PATCH for 4.15 00/24] Restartable sequences and CPU op vector v11

I have some comments that apply to many of the threads. I've been fully occupied with a wedding and a security issue; but I'm about to be free to spend the majority of my time on RSEQ things. I was sorely hoping that day would be today. But it's looking like I'm still a day or two from being free

Re: [RESEND PATCH 2/2] sched/fair: Optimize __update_sched_avg()

On Thu, Mar 30, 2017 at 7:14 AM, Peter Zijlstra <pet...@infradead.org> wrote: > On Thu, Mar 30, 2017 at 02:16:58PM +0200, Peter Zijlstra wrote: >> On Thu, Mar 30, 2017 at 04:21:08AM -0700, Paul Turner wrote: > >> > > + >> > > +

Re: [RESEND PATCH 2/2] sched/fair: Optimize __update_sched_avg()

On Thu, Mar 30, 2017 at 7:14 AM, Peter Zijlstra wrote: > On Thu, Mar 30, 2017 at 02:16:58PM +0200, Peter Zijlstra wrote: >> On Thu, Mar 30, 2017 at 04:21:08AM -0700, Paul Turner wrote: > >> > > + >> > > + if (unlikely(periods >= LOAD_AVG_MAX_N)) >

Re: [RESEND PATCH 2/2] sched/fair: Optimize __update_sched_avg()

On Fri, Mar 31, 2017 at 12:01 AM, Peter Zijlstra <pet...@infradead.org> wrote: > On Thu, Mar 30, 2017 at 03:02:47PM -0700, Paul Turner wrote: >> On Thu, Mar 30, 2017 at 7:14 AM, Peter Zijlstra <pet...@infradead.org> wrote: >> > On Thu, Mar 30, 2017 at 02:16:58

Re: [RESEND PATCH 2/2] sched/fair: Optimize __update_sched_avg()

On Fri, Mar 31, 2017 at 12:01 AM, Peter Zijlstra wrote: > On Thu, Mar 30, 2017 at 03:02:47PM -0700, Paul Turner wrote: >> On Thu, Mar 30, 2017 at 7:14 AM, Peter Zijlstra wrote: >> > On Thu, Mar 30, 2017 at 02:16:58PM +0200, Peter Zijlstra wrote: >> >> On Thu, Ma

Re: [RESEND PATCH 2/2] sched/fair: Optimize __update_sched_avg()

On Thu, Mar 30, 2017 at 7:14 AM, Peter Zijlstra <pet...@infradead.org> wrote: > On Thu, Mar 30, 2017 at 02:16:58PM +0200, Peter Zijlstra wrote: >> On Thu, Mar 30, 2017 at 04:21:08AM -0700, Paul Turner wrote: > >> > > + >> > > +

Re: [RESEND PATCH 2/2] sched/fair: Optimize __update_sched_avg()

On Thu, Mar 30, 2017 at 7:14 AM, Peter Zijlstra wrote: > On Thu, Mar 30, 2017 at 02:16:58PM +0200, Peter Zijlstra wrote: >> On Thu, Mar 30, 2017 at 04:21:08AM -0700, Paul Turner wrote: > >> > > + >> > > + if (unlikely(periods >= LOAD_AVG_MAX_N)) >

Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller

On Mon, Mar 20, 2017 at 11:08 AM, Patrick Bellasi wrote: > On 20-Mar 13:15, Tejun Heo wrote: >> Hello, >> >> On Tue, Feb 28, 2017 at 02:38:38PM +, Patrick Bellasi wrote: >> > This patch extends the CPU controller by adding a couple of new >> > attributes, capacity_min

Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller

On Mon, Mar 20, 2017 at 11:08 AM, Patrick Bellasi wrote: > On 20-Mar 13:15, Tejun Heo wrote: >> Hello, >> >> On Tue, Feb 28, 2017 at 02:38:38PM +, Patrick Bellasi wrote: >> > This patch extends the CPU controller by adding a couple of new >> > attributes, capacity_min and capacity_max, which

Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller

There is one important, fundamental difference here: {cfs,rt}_{period,runtime}_us is a property that applies to a group of threads, it can be sub-divided. We can consume 100ms of quota either by having one thread run for 100ms, or 2 threads running for 50ms. This is not true for capacity. It's

Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller

There is one important, fundamental difference here: {cfs,rt}_{period,runtime}_us is a property that applies to a group of threads, it can be sub-divided. We can consume 100ms of quota either by having one thread run for 100ms, or 2 threads running for 50ms. This is not true for capacity. It's

Re: [RESEND PATCH 2/2] sched/fair: Optimize __update_sched_avg()

> --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -2767,7 +2767,7 @@ static const u32 __accumulated_sum_N32[] > * Approximate: > * val * y^n,where y^32 ~= 0.5 (~1 scheduling period) > */ > -static __always_inline u64 decay_load(u64 val, u64 n) > +static u64 decay_load(u64

Re: [RESEND PATCH 2/2] sched/fair: Optimize __update_sched_avg()

> --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -2767,7 +2767,7 @@ static const u32 __accumulated_sum_N32[] > * Approximate: > * val * y^n,where y^32 ~= 0.5 (~1 scheduling period) > */ > -static __always_inline u64 decay_load(u64 val, u64 n) > +static u64 decay_load(u64

Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode

On Thu, Feb 2, 2017 at 12:06 PM, Tejun Heo wrote: > Hello, > > This patchset implements cgroup v2 thread mode. It is largely based > on the discussions that we had at the plumbers last year. Here's the > rough outline. > > * Thread mode is explicitly enabled on a cgroup by

Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode

On Thu, Feb 2, 2017 at 12:06 PM, Tejun Heo wrote: > Hello, > > This patchset implements cgroup v2 thread mode. It is largely based > on the discussions that we had at the plumbers last year. Here's the > rough outline. > > * Thread mode is explicitly enabled on a cgroup by writing "enable" >

Re: [PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

On Mon, Dec 19, 2016 at 3:29 PM, Samuel Thibault <samuel.thiba...@ens-lyon.org> wrote: > Paul Turner, on Mon 19 Dec 2016 15:26:19 -0800, wrote: >> >> > - if (shares < MIN_SHARES) >> >> > - shares = MIN_SHARES; >> > ... >

Re: [PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

On Mon, Dec 19, 2016 at 3:29 PM, Samuel Thibault wrote: > Paul Turner, on Mon 19 Dec 2016 15:26:19 -0800, wrote: >> >> > - if (shares < MIN_SHARES) >> >> > - shares = MIN_SHARES; >> > ... >> >> > return

Re: [PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

On Mon, Dec 19, 2016 at 3:07 PM, Samuel Thibault <samuel.thiba...@ens-lyon.org> wrote: > Paul Turner, on Mon 19 Dec 2016 14:44:38 -0800, wrote: >> On Mon, Dec 19, 2016 at 2:40 PM, Samuel Thibault >> <samuel.thiba...@ens-lyon.org> wrote: >> > 2159197d6677

Re: [PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

On Mon, Dec 19, 2016 at 3:07 PM, Samuel Thibault wrote: > Paul Turner, on Mon 19 Dec 2016 14:44:38 -0800, wrote: >> On Mon, Dec 19, 2016 at 2:40 PM, Samuel Thibault >> wrote: >> > 2159197d6677 ("sched/core: Enable increased load resolution on 64-bit >> > k

Re: [PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

On Mon, Dec 19, 2016 at 2:40 PM, Samuel Thibault wrote: > 2159197d6677 ("sched/core: Enable increased load resolution on 64-bit > kernels") > > exposed yet another miscalculation in calc_cfs_shares: MIN_SHARES is unscaled, > and must thus be scaled before being

Re: [PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

On Mon, Dec 19, 2016 at 2:40 PM, Samuel Thibault wrote: > 2159197d6677 ("sched/core: Enable increased load resolution on 64-bit > kernels") > > exposed yet another miscalculation in calc_cfs_shares: MIN_SHARES is unscaled, > and must thus be scaled before being manipulated against "shares"

Re: [RFC PATCH v8 1/9] Restartable sequences system call

c operations. >> >> The restartable critical sections (percpu atomics) work has been started >> by Paul Turner and Andrew Hunter. It lets the kernel handle restart of >> critical sections. [1] [2] The re-implementation proposed here brings a >> few simplifications to

Re: [RFC PATCH v8 1/9] Restartable sequences system call

; >> The restartable critical sections (percpu atomics) work has been started >> by Paul Turner and Andrew Hunter. It lets the kernel handle restart of >> critical sections. [1] [2] The re-implementation proposed here brings a >> few simplifications to the ABI which facilita

Re: [PATCH] sched/fair: Fix fixed point arithmetic width for shares and effective load

On Mon, Aug 22, 2016 at 7:00 AM, Dietmar Eggemann wrote: > > Since commit 2159197d6677 ("sched/core: Enable increased load resolution > on 64-bit kernels") we now have two different fixed point units for > load. > shares in calc_cfs_shares() has 20 bit fixed point unit

Re: [PATCH] sched/fair: Fix fixed point arithmetic width for shares and effective load

On Mon, Aug 22, 2016 at 7:00 AM, Dietmar Eggemann wrote: > > Since commit 2159197d6677 ("sched/core: Enable increased load resolution > on 64-bit kernels") we now have two different fixed point units for > load. > shares in calc_cfs_shares() has 20 bit fixed point unit on 64-bit > kernels.

Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers

NTR up to __lock_page; which does not validate the return code and blindly returns. This looks to have been a previously existing bug, but it was at least masked by the fact that it required a fatal signal previously (and that the page we return unlocked is likely going to be freed from the dying

Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers

t_on_bit_lock can return -EINTR up to __lock_page; which does not validate the return code and blindly returns. This looks to have been a previously existing bug, but it was at least masked by the fact that it required a fatal signal previously (and that the page we return unlocked is likely goi

Re: [PATCH 2/4] sched: Document Program-Order guarantees

On Mon, Nov 2, 2015 at 12:34 PM, Peter Zijlstra wrote: > On Mon, Nov 02, 2015 at 12:27:05PM -0800, Paul Turner wrote: >> I suspect this part might be more explicitly expressed by specifying >> the requirements that migration satisfies; then providing an example. >> This makes

Re: [PATCH] sched: Update task->on_rq when tasks are moving between runqueues

On Wed, Oct 28, 2015 at 6:58 PM, Peter Zijlstra wrote: > On Wed, Oct 28, 2015 at 05:57:10PM -0700, Olav Haugan wrote: >> On 15-10-25 11:09:24, Peter Zijlstra wrote: >> > On Sat, Oct 24, 2015 at 11:01:02AM -0700, Olav Haugan wrote: >> > > Task->on_rq has three states: >> > > 0 - Task is not on

Re: [PATCH 2/4] sched: Document Program-Order guarantees

On Mon, Nov 2, 2015 at 5:29 AM, Peter Zijlstra wrote: > These are some notes on the scheduler locking and how it provides > program order guarantees on SMP systems. > > Cc: Linus Torvalds > Cc: Will Deacon > Cc: Oleg Nesterov > Cc: Boqun Feng > Cc: "Paul E. McKenney" > Cc: Jonathan Corbet >

Re: [PATCH 2/4] sched: Document Program-Order guarantees

On Mon, Nov 2, 2015 at 5:29 AM, Peter Zijlstra wrote: > These are some notes on the scheduler locking and how it provides > program order guarantees on SMP systems. > > Cc: Linus Torvalds > Cc: Will Deacon > Cc: Oleg

Re: [PATCH] sched: Update task->on_rq when tasks are moving between runqueues

On Wed, Oct 28, 2015 at 6:58 PM, Peter Zijlstra wrote: > On Wed, Oct 28, 2015 at 05:57:10PM -0700, Olav Haugan wrote: >> On 15-10-25 11:09:24, Peter Zijlstra wrote: >> > On Sat, Oct 24, 2015 at 11:01:02AM -0700, Olav Haugan wrote: >> > > Task->on_rq has three states: >> > >

Re: [PATCH 2/4] sched: Document Program-Order guarantees

On Mon, Nov 2, 2015 at 12:34 PM, Peter Zijlstra <pet...@infradead.org> wrote: > On Mon, Nov 02, 2015 at 12:27:05PM -0800, Paul Turner wrote: >> I suspect this part might be more explicitly expressed by specifying >> the requirements that migration satisfies; then

Re: [RFC PATCH v2 2/3] restartable sequences: x86 ABI

On Tue, Oct 27, 2015 at 10:03 PM, Peter Zijlstra wrote: > > On Tue, Oct 27, 2015 at 04:57:05PM -0700, Paul Turner wrote: > > +static void rseq_sched_out(struct preempt_notifier *pn, > > +struct task_struct *next) > > +{ > > + set

[RFC PATCH v2 2/3] restartable sequences: x86 ABI

From: Paul Turner Recall the general ABI is: The kernel ABI generally consists of: a) A shared TLS word which exports the current cpu and event-count b) A shared TLS word which, when non-zero, stores the first post-commit instruction if a sequence is active. (The kernel

[RFC PATCH v2 3/3] restartable sequences: basic self-tests

nterrupted by signals. "basic_percpu_ops_test" is a slightly more "realistic" variant, implementing a few simple per-cpu operations and testing their correctness. It also includes a trivial example of user-space may multiplexing the critical section via the restart handle

[RFC PATCH 0/3] restartable sequences v2: fast user-space percpu critical sections

This is an update to the previously posted series at: https://lkml.org/lkml/2015/6/24/665 Dave Watson has posted a similar follow-up which allows additional critical regions to be registered as well as single-step support at: https://lkml.org/lkml/2015/10/22/588 This series is a new approach

[RFC PATCH v2 1/3] restartable sequences: user-space per-cpu critical sections

From: Paul Turner Introduce the notion of a restartable sequence. This is a piece of user code that can be described in 3 components: 1) Establish where [e.g. which cpu] the thread is running 2) Preparatory work that is dependent on the state in [1]. 3) A committing instruction

[RFC PATCH v2 2/3] restartable sequences: x86 ABI

From: Paul Turner <p...@google.com> Recall the general ABI is: The kernel ABI generally consists of: a) A shared TLS word which exports the current cpu and event-count b) A shared TLS word which, when non-zero, stores the first post-commit instruction if a sequence is

[RFC PATCH v2 3/3] restartable sequences: basic self-tests

ical section via the restart handler. Signed-off-by: Paul Turner <p...@google.com> --- tools/testing/selftests/rseq/Makefile | 13 + .../testing/selftests/rseq/basic_percpu_ops_test.c | 268 tools/testing/selftests/rseq/basic_test.c | 87 +

[RFC PATCH 0/3] restartable sequences v2: fast user-space percpu critical sections

This is an update to the previously posted series at: https://lkml.org/lkml/2015/6/24/665 Dave Watson has posted a similar follow-up which allows additional critical regions to be registered as well as single-step support at: https://lkml.org/lkml/2015/10/22/588 This series is a new approach

[RFC PATCH v2 1/3] restartable sequences: user-space per-cpu critical sections

From: Paul Turner <p...@google.com> Introduce the notion of a restartable sequence. This is a piece of user code that can be described in 3 components: 1) Establish where [e.g. which cpu] the thread is running 2) Preparatory work that is dependent on the state in [1]. 3) A comm

Re: [RFC PATCH v2 2/3] restartable sequences: x86 ABI

On Tue, Oct 27, 2015 at 10:03 PM, Peter Zijlstra <pet...@infradead.org> wrote: > > On Tue, Oct 27, 2015 at 04:57:05PM -0700, Paul Turner wrote: > > +static void rseq_sched_out(struct preempt_notifier *pn, > > +struct task_struct *next) > >

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On Thu, Oct 1, 2015 at 11:46 AM, Tejun Heo wrote: > Hello, Paul. > > Sorry about the delay. Things were kinda hectic in the past couple > weeks. Likewise :-( > > On Fri, Sep 18, 2015 at 04:27:07AM -0700, Paul Turner wrote: >> On Sat, Sep 12, 2015 at 7:40 AM, Tejun Heo

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On Thu, Oct 1, 2015 at 11:46 AM, Tejun Heo <t...@kernel.org> wrote: > Hello, Paul. > > Sorry about the delay. Things were kinda hectic in the past couple > weeks. Likewise :-( > > On Fri, Sep 18, 2015 at 04:27:07AM -0700, Paul Turner wrote: >> On Sat, Sep 12,

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On Sat, Sep 12, 2015 at 7:40 AM, Tejun Heo wrote: > Hello, > > On Wed, Sep 09, 2015 at 05:49:31AM -0700, Paul Turner wrote: >> I do not think this is a layering problem. This is more like C++: >> there is no sane way to concurrently use all the features available, >&g

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On Sat, Sep 12, 2015 at 7:40 AM, Tejun Heo <t...@kernel.org> wrote: > Hello, > > On Wed, Sep 09, 2015 at 05:49:31AM -0700, Paul Turner wrote: >> I do not think this is a layering problem. This is more like C++: >> there is no sane way to concurrently use all the fea

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

24, 2015 at 04:06:39PM -0700, Paul Turner wrote: >> > This is an erratic behavior on cpuset's part tho. Nothing else >> > behaves this way and it's borderline buggy. >> >> It's actually the only sane possible interaction here. >> >> If you don't o

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

gt; Hello, > > On Mon, Aug 24, 2015 at 04:06:39PM -0700, Paul Turner wrote: >> > This is an erratic behavior on cpuset's part tho. Nothing else >> > behaves this way and it's borderline buggy. >> >> It's actually the only sane possible interaction here. >> >>

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On Mon, Aug 24, 2015 at 3:49 PM, Tejun Heo wrote: > Hello, > > On Mon, Aug 24, 2015 at 03:03:05PM -0700, Paul Turner wrote: >> > Hmm... I was hoping for an actual configurations and usage scenarios. >> > Preferably something people can set up and play with. >>

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On Mon, Aug 24, 2015 at 3:19 PM, Tejun Heo wrote: > Hey, > > On Mon, Aug 24, 2015 at 02:58:23PM -0700, Paul Turner wrote: >> > Why isn't it? Because the programs themselves might try to override >> > it? >> >> The major reasons are: >> >> 1)

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On Mon, Aug 24, 2015 at 2:40 PM, Tejun Heo wrote: > On Mon, Aug 24, 2015 at 02:19:29PM -0700, Paul Turner wrote: >> > Would it be possible for you to give realistic and concrete examples? >> > I'm not trying to play down the use cases but concrete examples are >> &

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On Mon, Aug 24, 2015 at 2:36 PM, Tejun Heo wrote: > Hello, Paul. > > On Mon, Aug 24, 2015 at 01:52:01PM -0700, Paul Turner wrote: >> We typically share our machines between many jobs, these jobs can have >> cores that are "private" (and not shared with other jobs

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On Mon, Aug 24, 2015 at 2:17 PM, Tejun Heo wrote: > Hello, > > On Mon, Aug 24, 2015 at 02:10:17PM -0700, Paul Turner wrote: >> Suppose that we have 10 vcpu threads and 100 support threads. >> Suppose that we want the support threads to receive up to 10% of the >&g

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On Mon, Aug 24, 2015 at 2:12 PM, Tejun Heo wrote: > Hello, Paul. > > On Mon, Aug 24, 2015 at 02:00:54PM -0700, Paul Turner wrote: >> > Hmmm... I'm trying to understand the usecases where having hierarchy >> > inside a process are actually required so that we don't

  1   2   3   4   5   >