search for: zijlstra

On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote: > On 02/13/2017 02:42 PM, Waiman Long wrote: > > On 02/13/2017 05:53 AM, Peter Zijlstra wrote: > >> On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote: > >>> That way we'd end up with something like: > >>> > >>> asm(" > >>> push %rdi; > >>> movslq %edi, %rdi; > >>> movq __per_cpu_offs...

On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote: > On 02/13/2017 02:42 PM, Waiman Long wrote: > > On 02/13/2017 05:53 AM, Peter Zijlstra wrote: > >> On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote: > >>> That way we'd end up with something like: > >>> > >>> asm(" > >>> push %rdi; > >>> movslq %edi, %rdi; > >>> movq __per_cpu_offs...

...y pin a (virtual) cpu to a dedicated physical cpu for executing above mentioned functions on that specific cpu. The drivers (dcdbas and i8k) requiring this functionality are modified accordingly. Changes in V5: - patch 3: rename and reshuffle parameters of smp_call_on_cpu() as requested by Peter Zijlstra - patch 3: test target cpu to be online as requested by Peter Zijlstra - patch 4: less wordy messages as requested by David Vrabel Changes in V4: - move patches 5 and 6 further up in the series - patch 2 (was 5): WARN_ONCE in case platform doesn't support pinning as requested by Peter Zijlst...

...y pin a (virtual) cpu to a dedicated physical cpu for executing above mentioned functions on that specific cpu. The drivers (dcdbas and i8k) requiring this functionality are modified accordingly. Changes in V5: - patch 3: rename and reshuffle parameters of smp_call_on_cpu() as requested by Peter Zijlstra - patch 3: test target cpu to be online as requested by Peter Zijlstra - patch 4: less wordy messages as requested by David Vrabel Changes in V4: - move patches 5 and 6 further up in the series - patch 2 (was 5): WARN_ONCE in case platform doesn't support pinning as requested by Peter Zijlst...

On 06/07/16 08:52, Peter Zijlstra wrote: > On Tue, Jun 28, 2016 at 10:43:07AM -0400, Pan Xinhui wrote: >> change fomr v1: >> a simplier definition of default vcpu_is_preempted >> skip mahcine type check on ppc, and add config. remove dedicated macro. >> add one patch to drop overload of rwsem_spin_on_o...

On 06/07/16 08:52, Peter Zijlstra wrote: > On Tue, Jun 28, 2016 at 10:43:07AM -0400, Pan Xinhui wrote: >> change fomr v1: >> a simplier definition of default vcpu_is_preempted >> skip mahcine type check on ppc, and add config. remove dedicated macro. >> add one patch to drop overload of rwsem_spin_on_o...

On Tue, Jun 23, 2020 at 04:59:14PM +0200, Joerg Roedel wrote: > On Tue, Jun 23, 2020 at 04:53:44PM +0200, Peter Zijlstra wrote: > > +noinstr void idtentry_validate_ist(struct pt_regs *regs) > > +{ > > + if ((regs->sp & ~(EXCEPTION_STKSZ-1)) == > > + (_RET_IP_ & ~(EXCEPTION_STKSZ-1))) > > + die("IST stack recursion", regs, 0); > > +} > > Yes, this is...

...icated physical cpu for executing above > mentioned functions on that specific cpu. The drivers (dcdbas and i8k) > requiring this functionality are modified accordingly. > > Changes in V5: > - patch 3: rename and reshuffle parameters of smp_call_on_cpu() as requested > by Peter Zijlstra > - patch 3: test target cpu to be online as requested by Peter Zijlstra > - patch 4: less wordy messages as requested by David Vrabel > > Changes in V4: > - move patches 5 and 6 further up in the series > - patch 2 (was 5): WARN_ONCE in case platform doesn't support pinning...

On 02/13/2017 05:53 AM, Peter Zijlstra wrote: > On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote: >> That way we'd end up with something like: >> >> asm(" >> push %rdi; >> movslq %edi, %rdi; >> movq __per_cpu_offset(,%rdi,8), %rax; >> cmpb $0, %[offset](%rax); >>...

On 02/13/2017 05:53 AM, Peter Zijlstra wrote: > On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote: >> That way we'd end up with something like: >> >> asm(" >> push %rdi; >> movslq %edi, %rdi; >> movq __per_cpu_offset(,%rdi,8), %rax; >> cmpb $0, %[offset](%rax); >>...

...nd memory ordering in general, progresses. Nor does being mentioned in this document mean we think its a particularly good idea; the data dependency barrier required by Alpha being a prime example. Yes we have it, no you're insane to require it when building new hardware. Signed-off-by: Peter Zijlstra (Intel) <peterz at infradead.org> --- Documentation/memory-barriers.txt | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index a61be39c7b51..98626125f484 100644 --- a/Documentation/mem...

...nd memory ordering in general, progresses. Nor does being mentioned in this document mean we think its a particularly good idea; the data dependency barrier required by Alpha being a prime example. Yes we have it, no you're insane to require it when building new hardware. Signed-off-by: Peter Zijlstra (Intel) <peterz at infradead.org> --- Documentation/memory-barriers.txt | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index a61be39c7b51..98626125f484 100644 --- a/Documentation/mem...

On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote: > On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote: > > Urgh, is for some mysterious reason the __bug_table section of modules > > ending up in RO memory? > > > > I forever get lost in that link magic :/ > > +1 > > drm.ko >  20 __bug_table   00000630  0000000000000000  0000000000000000  0004bff3  2**...

On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote: > 2) the changelog _completely_ fails to explain the sync 0x11 and sync > 0x12 semantics nor does it provide a publicly accessible link to > documentation that does. Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/ > 3) it really should have explained what you...

On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote: > 2) the changelog _completely_ fails to explain the sync 0x11 and sync > 0x12 semantics nor does it provide a publicly accessible link to > documentation that does. Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/ > 3) it really should have explained what you...

On Tue, Jan 26, 2016 at 11:32:00AM +0100, Peter Zijlstra wrote: > On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > > > Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > > specification (I seem to keep repeating this). > > Do we want this ? > > --- > Documentation/memory-barriers.txt |...

On Tue, Jan 26, 2016 at 11:32:00AM +0100, Peter Zijlstra wrote: > On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > > > Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > > specification (I seem to keep repeating this). > > Do we want this ? > > --- > Documentation/memory-barriers.txt |...

On Wed, Apr 01, 2015 at 02:54:45PM -0400, Waiman Long wrote: > On 04/01/2015 02:17 PM, Peter Zijlstra wrote: > >On Wed, Apr 01, 2015 at 07:42:39PM +0200, Peter Zijlstra wrote: > >>>Hohumm.. time to think more I think ;-) > >>So bear with me, I've not really pondered this well so it could be full > >>of holes (again). > >> > >>After the cmpxc...

On Wed, Apr 01, 2015 at 02:54:45PM -0400, Waiman Long wrote: > On 04/01/2015 02:17 PM, Peter Zijlstra wrote: > >On Wed, Apr 01, 2015 at 07:42:39PM +0200, Peter Zijlstra wrote: > >>>Hohumm.. time to think more I think ;-) > >>So bear with me, I've not really pondered this well so it could be full > >>of holes (again). > >> > >>After the cmpxc...

On Fri, Nov 25, 2016 at 01:40:44PM +0100, Peter Zijlstra wrote: > #define SINGLE_LOAD(x) \ > {( \ > compiletime_assert_atomic_type(typeof(x)); \ Should be: compiletime_assert_atomic_type(x); > WARN_SINGLE_COPY_ALIGNMENT(&(x)); \ > READ_ONCE(x); \ > }) > > #define SINGLE_STORE(x, v) \ > ({...