search for: spinloop

...39;monotonic' ordering, > ... "If an address is written monotonically by one thread, and other > threads monotonically read that address repeatedly, the other threads > must eventually see the write"... It's supposed to mean that if you have a something like looks like a spinloop with monotonic reads, it shouldn't spin forever if the value changes. I'll take another look at rewording that. > Does this mean if a thread does multi-writes monotonically, monotonic > reads from other threads should see all of them? But intuitively, it > seems to be fine for a...

...;If an address is written monotonically by one thread, and other >>> threads monotonically read that address repeatedly, the other threads >>> must eventually see the write"... >> >> It's supposed to mean that if you have a something like looks like a >> spinloop with monotonic reads, it shouldn't spin forever if the value >> changes.  I'll take another look at rewording that. >> >>> Does this mean if a thread does multi-writes monotonically, monotonic >>> reads from other threads should see all of them? But intuitively...

..., >> ... "If an address is written monotonically by one thread, and other >> threads monotonically read that address repeatedly, the other threads >> must eventually see the write"... > > It's supposed to mean that if you have a something like looks like a > spinloop with monotonic reads, it shouldn't spin forever if the value > changes.  I'll take another look at rewording that. > >> Does this mean if a thread does multi-writes monotonically, monotonic >> reads from other threads should see all of them? But intuitively, it >> se...

...itten monotonically by one thread, and other >>>> threads monotonically read that address repeatedly, the other threads >>>> must eventually see the write"... >>> >>> It's supposed to mean that if you have a something like looks like a >>> spinloop with monotonic reads, it shouldn't spin forever if the value >>> changes.  I'll take another look at rewording that. >>> >>>> Does this mean if a thread does multi-writes monotonically, monotonic >>>> reads from other threads should see all of them?...

...itten monotonically by one thread, and other >>>> threads monotonically read that address repeatedly, the other threads >>>> must eventually see the write"... >>> >>> It's supposed to mean that if you have a something like looks like a >>> spinloop with monotonic reads, it shouldn't spin forever if the value >>> changes.  I'll take another look at rewording that. >>> >>>> Does this mean if a thread does multi-writes monotonically, monotonic >>>> reads from other threads should see all of them?...

In the definition of 'monotonic' ordering, ... "If an address is written monotonically by one thread, and other threads monotonically read that address repeatedly, the other threads must eventually see the write"... Does this mean if a thread does multi-writes monotonically, monotonic reads from other threads should see all of them? But intuitively, it seems to be fine for a

Hi, In the case of linux, crash_kexec() is occured by "sysrq c". In the case of DomainU on xen, Help is occured by "sysrq c" now. So The way of dumping DomainU''s memory manualy is nothing. I fix this issue by the following way. 1. Panic is occured by "sysrq c" on both Domain0 and DomainU. 2. On DomainU, coredump is generated in /var/xen/dump (on Domain0).

There was some discussion a while back about adding a C++0x-style memory model and atomics for LLVM a while back (http://thread.gmane.org/gmane.comp.compilers.llvm.devel/31295), but it got stalled. I'm going to try and restart progress on it. Attached are two patches; the first adds a section to LangRef with just the memory model, without directly changing the documentation or implementation

This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM. Changes in V9: - Changed spin_threshold to 32k to avoid excess halt exits that are causing undercommit degradation (after PLE handler improvement). - Added kvm_irq_delivery_to_apic (suggested by Gleb) - Optimized halt exit

This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM. Changes in V9: - Changed spin_threshold to 32k to avoid excess halt exits that are causing undercommit degradation (after PLE handler improvement). - Added kvm_irq_delivery_to_apic (suggested by Gleb) - Optimized halt exit

This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM. Changes in V9: - Changed spin_threshold to 32k to avoid excess halt exits that are causing undercommit degradation (after PLE handler improvement). - Added kvm_irq_delivery_to_apic (suggested by Gleb) - Optimized halt exit

This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM. Changes in V10: Addressed Konrad's review comments: - Added break in patch 5 since now we know exact cpu to wakeup - Dropped patch 12 and Konrad needs to revert two patches to enable xen on hvm 70dd4998, f10cd522c -

This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM. Changes in V10: Addressed Konrad's review comments: - Added break in patch 5 since now we know exact cpu to wakeup - Dropped patch 12 and Konrad needs to revert two patches to enable xen on hvm 70dd4998, f10cd522c -

This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM. Changes in V10: Addressed Konrad's review comments: - Added break in patch 5 since now we know exact cpu to wakeup - Dropped patch 12 and Konrad needs to revert two patches to enable xen on hvm 70dd4998, f10cd522c -

This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM. Changes in V11: - use safe_halt in lock_spinning path to avoid potential problem in case of irq_handlers taking lock in slowpath (Gleb) - add a0 flag for the kick hypercall for future extension (Gleb) - add stubs for

This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM. Changes in V11: - use safe_halt in lock_spinning path to avoid potential problem in case of irq_handlers taking lock in slowpath (Gleb) - add a0 flag for the kick hypercall for future extension (Gleb) - add stubs for

This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM. Changes in V11: - use safe_halt in lock_spinning path to avoid potential problem in case of irq_handlers taking lock in slowpath (Gleb) - add a0 flag for the kick hypercall for future extension (Gleb) - add stubs for