search for: notify_next

...y_qcode, > + _QSPINLOCK_LOCKED) == my_qcode) > + goto release_node; > + /* > + * The cmpxchg fails only if one or more tasks > + * are added to the queue. In this case, we need to > + * notify the next one to be the head of the queue. > + */ > + goto notify_next; > + } > + /* > + * Accidentally steal the lock, release the lock and > + * let the queue head get it. > + */ > + queue_spin_unlock(lock); > + } else > + prev_qcode &= ~_QSPINLOCK_LOCKED; /* Clear the lock bit */ You know, actually I started this email because...

...y_qcode, > + _QSPINLOCK_LOCKED) == my_qcode) > + goto release_node; > + /* > + * The cmpxchg fails only if one or more tasks > + * are added to the queue. In this case, we need to > + * notify the next one to be the head of the queue. > + */ > + goto notify_next; > + } > + /* > + * Accidentally steal the lock, release the lock and > + * let the queue head get it. > + */ > + queue_spin_unlock(lock); > + } else > + prev_qcode &= ~_QSPINLOCK_LOCKED; /* Clear the lock bit */ You know, actually I started this email because...

...g flags; - - if (WARN_ON(kernfs_type(kn) != KERNFS_FILE)) +repeat: + /* pop one off the notify_list */ + spin_lock_irq(&kernfs_notify_lock); + kn = kernfs_notify_list; + if (kn == KERNFS_NOTIFY_EOL) { + spin_unlock_irq(&kernfs_notify_lock); return; + } + kernfs_notify_list = kn->attr.notify_next; + kn->attr.notify_next = NULL; + spin_unlock_irq(&kernfs_notify_lock); /* kick poll */ - spin_lock_irqsave(&kernfs_open_node_lock, flags); + spin_lock_irq(&kernfs_open_node_lock); on = kn->attr.open; if (on) { @@ -808,12 +822,12 @@ void kernfs_notify(struct kernfs_node...

...g flags; - - if (WARN_ON(kernfs_type(kn) != KERNFS_FILE)) +repeat: + /* pop one off the notify_list */ + spin_lock_irq(&kernfs_notify_lock); + kn = kernfs_notify_list; + if (kn == KERNFS_NOTIFY_EOL) { + spin_unlock_irq(&kernfs_notify_lock); return; + } + kernfs_notify_list = kn->attr.notify_next; + kn->attr.notify_next = NULL; + spin_unlock_irq(&kernfs_notify_lock); /* kick poll */ - spin_lock_irqsave(&kernfs_open_node_lock, flags); + spin_lock_irq(&kernfs_open_node_lock); on = kn->attr.open; if (on) { @@ -808,12 +822,12 @@ void kernfs_notify(struct kernfs_node...

On 06/29/2014 02:47 PM, Michael S. Tsirkin wrote: > On Sun, Jun 29, 2014 at 09:32:22PM +0200, Christoph Hellwig wrote: >> On Sun, Jun 29, 2014 at 11:26:37AM +0300, Michael S. Tsirkin wrote: >>> On Fri, Jun 27, 2014 at 07:57:38AM -0400, Josh Boyer wrote: >>>> Hi All, >>>> >>>> We've had a report[1] of the virt_blk driver causing a lot of

On 06/29/2014 02:47 PM, Michael S. Tsirkin wrote: > On Sun, Jun 29, 2014 at 09:32:22PM +0200, Christoph Hellwig wrote: >> On Sun, Jun 29, 2014 at 11:26:37AM +0300, Michael S. Tsirkin wrote: >>> On Fri, Jun 27, 2014 at 07:57:38AM -0400, Josh Boyer wrote: >>>> Hi All, >>>> >>>> We've had a report[1] of the virt_blk driver causing a lot of

Hi, I have one user constantly crashing with: Core was generated by `dovecot/imap'. Program terminated with signal 11, Segmentation fault. #0 0x007e5b7c in mailbox_list_notify_next (notify=0x0, rec_r=0xbfee8f00) at mailbox-list-notify.c:28 28 return notify->list->v.notify_next(notify, rec_r); (gdb) bt #0 0x007e5b7c in mailbox_list_notify_next (notify=0x0, rec_r=0xbfee8f00) at mailbox-list-notify.c:28 #1 0x080641f2 in imap_client_notify_ns (notify_ns=0x8...

...+ * As the value 0 cannot be used as a valid CPU number. We need to add + * 1 to it before putting it into the queue code. + */ +#define MAX_QNODES 4 +#ifndef _QCODE_VAL_OFFSET +#define _QCODE_VAL_OFFSET _QCODE_OFFSET +#endif + +/* + * Function exit status + */ +enum exitval { + NORMAL_EXIT = 0, + NOTIFY_NEXT , /* Notify the next waiting node CPU */ + RELEASE_NODE /* Release current node directly */ +}; + +/* + * The queue node structure + * + * This structure is essentially the same as the mcs_spinlock structure + * in mcs_spinlock.h file. It is retained for future extension where new + * fields...

Forgot to ask... On 02/26, Waiman Long wrote: > > +notify_next: > + /* > + * Wait, if needed, until the next one in queue set up the next field > + */ > + while (!(next = ACCESS_ONCE(node->next))) > + arch_mutex_cpu_relax(); > + /* > + * The next one in queue is now at the head > + */ > + smp_store_release(&next->wait,...

Forgot to ask... On 02/26, Waiman Long wrote: > > +notify_next: > + /* > + * Wait, if needed, until the next one in queue set up the next field > + */ > + while (!(next = ACCESS_ONCE(node->next))) > + arch_mutex_cpu_relax(); > + /* > + * The next one in queue is now at the head > + */ > + smp_store_release(&next->wait,...

v6->v7: - Remove an atomic operation from the 2-task contending code - Shorten the names of some macros - Make the queue waiter to attempt to steal lock when unfair lock is enabled. - Remove lock holder kick from the PV code and fix a race condition - Run the unfair lock & PV code on overcommitted KVM guests to collect performance data. v5->v6: - Change the optimized

v6->v7: - Remove an atomic operation from the 2-task contending code - Shorten the names of some macros - Make the queue waiter to attempt to steal lock when unfair lock is enabled. - Remove lock holder kick from the PV code and fix a race condition - Run the unfair lock & PV code on overcommitted KVM guests to collect performance data. v5->v6: - Change the optimized

v7->v8: - Remove one unneeded atomic operation from the slowpath, thus improving performance. - Simplify some of the codes and add more comments. - Test for X86_FEATURE_HYPERVISOR CPU feature bit to enable/disable unfair lock. - Reduce unfair lock slowpath lock stealing frequency depending on its distance from the queue head. - Add performance data for IvyBridge-EX CPU.

v7->v8: - Remove one unneeded atomic operation from the slowpath, thus improving performance. - Simplify some of the codes and add more comments. - Test for X86_FEATURE_HYPERVISOR CPU feature bit to enable/disable unfair lock. - Reduce unfair lock slowpath lock stealing frequency depending on its distance from the queue head. - Add performance data for IvyBridge-EX CPU.

N.B. Sorry for the duplicate. This patch series were resent as the original one was rejected by the vger.kernel.org list server due to long header. There is no change in content. v7->v8: - Remove one unneeded atomic operation from the slowpath, thus improving performance. - Simplify some of the codes and add more comments. - Test for X86_FEATURE_HYPERVISOR CPU feature bit

N.B. Sorry for the duplicate. This patch series were resent as the original one was rejected by the vger.kernel.org list server due to long header. There is no change in content. v7->v8: - Remove one unneeded atomic operation from the slowpath, thus improving performance. - Simplify some of the codes and add more comments. - Test for X86_FEATURE_HYPERVISOR CPU feature bit

v4->v5: - Move the optimized 2-task contending code to the generic file to enable more architectures to use it without code duplication. - Address some of the style-related comments by PeterZ. - Allow the use of unfair queue spinlock in a real para-virtualized execution environment. - Add para-virtualization support to the qspinlock code by ensuring that the lock holder and queue

v4->v5: - Move the optimized 2-task contending code to the generic file to enable more architectures to use it without code duplication. - Address some of the style-related comments by PeterZ. - Allow the use of unfair queue spinlock in a real para-virtualized execution environment. - Add para-virtualization support to the qspinlock code by ensuring that the lock holder and queue

Hi All, I also tried with 16ff395c156e and 3d576d682137 patches that touch lib-storage/notify and still 2.2.19 cores: Core was generated by `dovecot/imap'. Program terminated with signal 11, Segmentation fault. #0 0x0043bb8c in mailbox_list_notify_next (notify=0x0, rec_r=0xbfdb34a0) at mailbox-list-notify.c:28 28 return notify->list->v.notify_next(notify, rec_r); (gdb) bt #0 0x0043bb8c in mailbox_list_notify_next (notify=0x0, rec_r=0xbfdb34a0) at mailbox-list-notify.c:28 #1 0x080641f2 in imap_client_notify_ns (notify_ns=0x9...

...tila wrote: > Hi All, > > I also tried with 16ff395c156e and 3d576d682137 patches that touch > lib-storage/notify and still 2.2.19 cores: > > Core was generated by `dovecot/imap'. > Program terminated with signal 11, Segmentation fault. > #0 0x0043bb8c in mailbox_list_notify_next (notify=0x0, > rec_r=0xbfdb34a0) at mailbox-list-notify.c:28 > 28 return notify->list->v.notify_next(notify, rec_r); > (gdb) bt > #0 0x0043bb8c in mailbox_list_notify_next (notify=0x0, > rec_r=0xbfdb34a0) at mailbox-list-notify.c:28 > #1 0x080641f2 in imap_cli...