On 11/14/2017 07:17 PM, Peter Zijlstra wrote:
> On Tue, Nov 14, 2017 at 07:01:55PM +0100, Daniel Bristot de Oliveira wrote:
>> On 11/14/2017 06:40 PM, Peter Zijlstra wrote:
>>> On Tue, Nov 14, 2017 at 06:17:13PM +0100, Daniel Bristot de Oliveira wrote:
>>>
IIRC, if the dest cpu is idle and
On 11/14/2017 07:17 PM, Peter Zijlstra wrote:
> On Tue, Nov 14, 2017 at 07:01:55PM +0100, Daniel Bristot de Oliveira wrote:
>> On 11/14/2017 06:40 PM, Peter Zijlstra wrote:
>>> On Tue, Nov 14, 2017 at 06:17:13PM +0100, Daniel Bristot de Oliveira wrote:
>>>
IIRC, if the dest cpu is idle and
On Tue, Nov 14, 2017 at 07:01:55PM +0100, Daniel Bristot de Oliveira wrote:
> On 11/14/2017 06:40 PM, Peter Zijlstra wrote:
> > On Tue, Nov 14, 2017 at 06:17:13PM +0100, Daniel Bristot de Oliveira wrote:
> >
> >> IIRC, if the dest cpu is idle and the system is with idle=poll, no IPI
> >> is fired
On Tue, Nov 14, 2017 at 07:01:55PM +0100, Daniel Bristot de Oliveira wrote:
> On 11/14/2017 06:40 PM, Peter Zijlstra wrote:
> > On Tue, Nov 14, 2017 at 06:17:13PM +0100, Daniel Bristot de Oliveira wrote:
> >
> >> IIRC, if the dest cpu is idle and the system is with idle=poll, no IPI
> >> is fired
On 11/14/2017 06:40 PM, Peter Zijlstra wrote:
> On Tue, Nov 14, 2017 at 06:17:13PM +0100, Daniel Bristot de Oliveira wrote:
>
>> IIRC, if the dest cpu is idle and the system is with idle=poll, no IPI
>> is fired as well, but that is not a very common case.
>
> You're thinking about wake from
On 11/14/2017 06:40 PM, Peter Zijlstra wrote:
> On Tue, Nov 14, 2017 at 06:17:13PM +0100, Daniel Bristot de Oliveira wrote:
>
>> IIRC, if the dest cpu is idle and the system is with idle=poll, no IPI
>> is fired as well, but that is not a very common case.
>
> You're thinking about wake from
On Tue, Nov 14, 2017 at 06:17:13PM +0100, Daniel Bristot de Oliveira wrote:
> IIRC, if the dest cpu is idle and the system is with idle=poll, no IPI
> is fired as well, but that is not a very common case.
You're thinking about wake from idle? That is almost always without IPI,
even without
On Tue, Nov 14, 2017 at 06:17:13PM +0100, Daniel Bristot de Oliveira wrote:
> IIRC, if the dest cpu is idle and the system is with idle=poll, no IPI
> is fired as well, but that is not a very common case.
You're thinking about wake from idle? That is almost always without IPI,
even without
On Tue, Nov 14, 2017 at 9:10 AM, Mathieu Desnoyers
wrote:
>> (* OPTION 1 *)
>> Store modified code (as data) into code segment;
>> Jump to new code or an intermediate location;
>> Execute new code;"
>
> Good point, so this is likely why I was having trouble
On Tue, Nov 14, 2017 at 9:10 AM, Mathieu Desnoyers
wrote:
>> (* OPTION 1 *)
>> Store modified code (as data) into code segment;
>> Jump to new code or an intermediate location;
>> Execute new code;"
>
> Good point, so this is likely why I was having trouble reproducing the
> single-threaded
On 11/14/2017 05:31 PM, Peter Zijlstra wrote:
> On Tue, Nov 14, 2017 at 08:16:09AM -0800, Andy Lutomirski wrote:
>> What guarantees that there's an IPI? Do we never do a syscall, get
>> migrated during syscall processing (due to cond_resched(), for
>> example), and land on another CPU that just
On 11/14/2017 05:31 PM, Peter Zijlstra wrote:
> On Tue, Nov 14, 2017 at 08:16:09AM -0800, Andy Lutomirski wrote:
>> What guarantees that there's an IPI? Do we never do a syscall, get
>> migrated during syscall processing (due to cond_resched(), for
>> example), and land on another CPU that just
- On Nov 14, 2017, at 12:03 PM, Avi Kivity a...@scylladb.com wrote:
> On 11/14/2017 06:49 PM, Mathieu Desnoyers wrote:
>> - On Nov 14, 2017, at 11:08 AM, Peter Zijlstra pet...@infradead.org
>> wrote:
>>
>>> On Tue, Nov 14, 2017 at 05:05:41PM +0100, Peter Zijlstra wrote:
On Tue, Nov
- On Nov 14, 2017, at 12:03 PM, Avi Kivity a...@scylladb.com wrote:
> On 11/14/2017 06:49 PM, Mathieu Desnoyers wrote:
>> - On Nov 14, 2017, at 11:08 AM, Peter Zijlstra pet...@infradead.org
>> wrote:
>>
>>> On Tue, Nov 14, 2017 at 05:05:41PM +0100, Peter Zijlstra wrote:
On Tue, Nov
On 11/14/2017 06:49 PM, Mathieu Desnoyers wrote:
- On Nov 14, 2017, at 11:08 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, Nov 14, 2017 at 05:05:41PM +0100, Peter Zijlstra wrote:
On Tue, Nov 14, 2017 at 03:17:12PM +, Mathieu Desnoyers wrote:
I've tried to create a small
On 11/14/2017 06:49 PM, Mathieu Desnoyers wrote:
- On Nov 14, 2017, at 11:08 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, Nov 14, 2017 at 05:05:41PM +0100, Peter Zijlstra wrote:
On Tue, Nov 14, 2017 at 03:17:12PM +, Mathieu Desnoyers wrote:
I've tried to create a small
- On Nov 14, 2017, at 11:08 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Nov 14, 2017 at 05:05:41PM +0100, Peter Zijlstra wrote:
>> On Tue, Nov 14, 2017 at 03:17:12PM +, Mathieu Desnoyers wrote:
>> > I've tried to create a small single-threaded self-modifying loop in
>> >
- On Nov 14, 2017, at 11:08 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Nov 14, 2017 at 05:05:41PM +0100, Peter Zijlstra wrote:
>> On Tue, Nov 14, 2017 at 03:17:12PM +, Mathieu Desnoyers wrote:
>> > I've tried to create a small single-threaded self-modifying loop in
>> >
On Tue, Nov 14, 2017 at 08:16:09AM -0800, Andy Lutomirski wrote:
> What guarantees that there's an IPI? Do we never do a syscall, get
> migrated during syscall processing (due to cond_resched(), for
> example), and land on another CPU that just happened to already be
> scheduling?
Possible, the
On Tue, Nov 14, 2017 at 08:16:09AM -0800, Andy Lutomirski wrote:
> What guarantees that there's an IPI? Do we never do a syscall, get
> migrated during syscall processing (due to cond_resched(), for
> example), and land on another CPU that just happened to already be
> scheduling?
Possible, the
On Tue, Nov 14, 2017 at 8:13 AM, Thomas Gleixner wrote:
> On Tue, 14 Nov 2017, Andy Lutomirski wrote:
>> On Tue, Nov 14, 2017 at 8:05 AM, Peter Zijlstra wrote:
>> > On Tue, Nov 14, 2017 at 03:17:12PM +, Mathieu Desnoyers wrote:
>> >> I've tried to
On Tue, Nov 14, 2017 at 8:13 AM, Thomas Gleixner wrote:
> On Tue, 14 Nov 2017, Andy Lutomirski wrote:
>> On Tue, Nov 14, 2017 at 8:05 AM, Peter Zijlstra wrote:
>> > On Tue, Nov 14, 2017 at 03:17:12PM +, Mathieu Desnoyers wrote:
>> >> I've tried to create a small single-threaded
On Tue, 14 Nov 2017, Andy Lutomirski wrote:
> On Tue, Nov 14, 2017 at 8:05 AM, Peter Zijlstra wrote:
> > On Tue, Nov 14, 2017 at 03:17:12PM +, Mathieu Desnoyers wrote:
> >> I've tried to create a small single-threaded self-modifying loop in
> >> user-space to trigger a
On Tue, 14 Nov 2017, Andy Lutomirski wrote:
> On Tue, Nov 14, 2017 at 8:05 AM, Peter Zijlstra wrote:
> > On Tue, Nov 14, 2017 at 03:17:12PM +, Mathieu Desnoyers wrote:
> >> I've tried to create a small single-threaded self-modifying loop in
> >> user-space to trigger a trace cache or
On Tue, Nov 14, 2017 at 8:05 AM, Peter Zijlstra wrote:
> On Tue, Nov 14, 2017 at 03:17:12PM +, Mathieu Desnoyers wrote:
>> I've tried to create a small single-threaded self-modifying loop in
>> user-space to trigger a trace cache or speculative execution quirk,
>> but I
On Tue, Nov 14, 2017 at 8:05 AM, Peter Zijlstra wrote:
> On Tue, Nov 14, 2017 at 03:17:12PM +, Mathieu Desnoyers wrote:
>> I've tried to create a small single-threaded self-modifying loop in
>> user-space to trigger a trace cache or speculative execution quirk,
>> but I have not succeeded
On Tue, Nov 14, 2017 at 05:05:41PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 14, 2017 at 03:17:12PM +, Mathieu Desnoyers wrote:
> > I've tried to create a small single-threaded self-modifying loop in
> > user-space to trigger a trace cache or speculative execution quirk,
> > but I have not
On Tue, Nov 14, 2017 at 05:05:41PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 14, 2017 at 03:17:12PM +, Mathieu Desnoyers wrote:
> > I've tried to create a small single-threaded self-modifying loop in
> > user-space to trigger a trace cache or speculative execution quirk,
> > but I have not
On Tue, Nov 14, 2017 at 03:17:12PM +, Mathieu Desnoyers wrote:
> I've tried to create a small single-threaded self-modifying loop in
> user-space to trigger a trace cache or speculative execution quirk,
> but I have not succeeded yet. I suspect that I would need to know
> more about the
On Tue, Nov 14, 2017 at 03:17:12PM +, Mathieu Desnoyers wrote:
> I've tried to create a small single-threaded self-modifying loop in
> user-space to trigger a trace cache or speculative execution quirk,
> but I have not succeeded yet. I suspect that I would need to know
> more about the
On 11/14/2017 05:17 PM, Mathieu Desnoyers wrote:
- On Nov 14, 2017, at 9:53 AM, Avi Kivity a...@scylladb.com wrote:
On 11/13/2017 06:56 PM, Mathieu Desnoyers wrote:
- On Nov 10, 2017, at 4:57 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
- On Nov 10, 2017, at
On 11/14/2017 05:17 PM, Mathieu Desnoyers wrote:
- On Nov 14, 2017, at 9:53 AM, Avi Kivity a...@scylladb.com wrote:
On 11/13/2017 06:56 PM, Mathieu Desnoyers wrote:
- On Nov 10, 2017, at 4:57 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
- On Nov 10, 2017, at
- On Nov 14, 2017, at 9:53 AM, Avi Kivity a...@scylladb.com wrote:
> On 11/13/2017 06:56 PM, Mathieu Desnoyers wrote:
>> - On Nov 10, 2017, at 4:57 PM, Mathieu Desnoyers
>> mathieu.desnoy...@efficios.com wrote:
>>
>>> - On Nov 10, 2017, at 4:36 PM, Linus Torvalds
>>>
- On Nov 14, 2017, at 9:53 AM, Avi Kivity a...@scylladb.com wrote:
> On 11/13/2017 06:56 PM, Mathieu Desnoyers wrote:
>> - On Nov 10, 2017, at 4:57 PM, Mathieu Desnoyers
>> mathieu.desnoy...@efficios.com wrote:
>>
>>> - On Nov 10, 2017, at 4:36 PM, Linus Torvalds
>>>
On 11/13/2017 06:56 PM, Mathieu Desnoyers wrote:
- On Nov 10, 2017, at 4:57 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
- On Nov 10, 2017, at 4:36 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
On Fri, Nov 10, 2017 at 1:12 PM, Mathieu Desnoyers
On 11/13/2017 06:56 PM, Mathieu Desnoyers wrote:
- On Nov 10, 2017, at 4:57 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
- On Nov 10, 2017, at 4:36 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
On Fri, Nov 10, 2017 at 1:12 PM, Mathieu Desnoyers
wrote:
On Mon, Nov 13, 2017 at 8:56 AM, Mathieu Desnoyers
wrote:
>
> I figured out what you're pointing to: if exec() is executed by a previously
> running thread, and there is no core serializing instruction between program
> load and return to user-space, the kernel
On Mon, Nov 13, 2017 at 8:56 AM, Mathieu Desnoyers
wrote:
>
> I figured out what you're pointing to: if exec() is executed by a previously
> running thread, and there is no core serializing instruction between program
> load and return to user-space, the kernel ends up acting like a JIT, indeed.
- On Nov 10, 2017, at 4:57 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Nov 10, 2017, at 4:36 PM, Linus Torvalds
> torva...@linux-foundation.org
> wrote:
>
>> On Fri, Nov 10, 2017 at 1:12 PM, Mathieu Desnoyers
>> wrote:
>>> x86 can
- On Nov 10, 2017, at 4:57 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Nov 10, 2017, at 4:36 PM, Linus Torvalds
> torva...@linux-foundation.org
> wrote:
>
>> On Fri, Nov 10, 2017 at 1:12 PM, Mathieu Desnoyers
>> wrote:
>>> x86 can return to user-space through
On Fri, Nov 10, 2017 at 1:57 PM, Mathieu Desnoyers
wrote:
>
> That core serializing instruction is not that much about I$ vs D$
> consistency, but rather about the processor speculatively executing code
> ahead of its retirement point. Ref. Intel Architecture
On Fri, Nov 10, 2017 at 1:57 PM, Mathieu Desnoyers
wrote:
>
> That core serializing instruction is not that much about I$ vs D$
> consistency, but rather about the processor speculatively executing code
> ahead of its retirement point. Ref. Intel Architecture Software Developer's
> Manual, Volume
- On Nov 10, 2017, at 4:36 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Fri, Nov 10, 2017 at 1:12 PM, Mathieu Desnoyers
> wrote:
>> x86 can return to user-space through sysexit and sysretq, which are not
>> core serializing. This breaks
- On Nov 10, 2017, at 4:36 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Fri, Nov 10, 2017 at 1:12 PM, Mathieu Desnoyers
> wrote:
>> x86 can return to user-space through sysexit and sysretq, which are not
>> core serializing. This breaks expectations from user-space about
>>
On Fri, Nov 10, 2017 at 1:12 PM, Mathieu Desnoyers
wrote:
> x86 can return to user-space through sysexit and sysretq, which are not
> core serializing. This breaks expectations from user-space about
> sequential consistency from a single-threaded self-modifying
On Fri, Nov 10, 2017 at 1:12 PM, Mathieu Desnoyers
wrote:
> x86 can return to user-space through sysexit and sysretq, which are not
> core serializing. This breaks expectations from user-space about
> sequential consistency from a single-threaded self-modifying program
> point of view in specific
x86 can return to user-space through sysexit and sysretq, which are not
core serializing. This breaks expectations from user-space about
sequential consistency from a single-threaded self-modifying program
point of view in specific migration patterns.
Feedback is welcome,
Thanks,
Mathieu
x86 can return to user-space through sysexit and sysretq, which are not
core serializing. This breaks expectations from user-space about
sequential consistency from a single-threaded self-modifying program
point of view in specific migration patterns.
Feedback is welcome,
Thanks,
Mathieu
48 matches
Mail list logo