| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20081023141232.GC8483@sgi.com> Date: Thu, 23 Oct 2008 09:12:32 -0500 From: Robin Holt <holt@....com> To: Rick Jones <rick.jones2@...com> Cc: Petr Tesarik <ptesarik@...e.cz>, linux-kernel@...r.kernel.org, linux-ia64@...r.kernel.org, tee@....com Subject: Re: [PATCH 0/2] enable irqs when waiting for rwlocks On Wed, Oct 22, 2008 at 10:31:53AM -0700, Rick Jones wrote: > Petr Tesarik wrote: >> Hello, >> >> SGI has observed that on large systems, interrupts are not serviced for >> a long period of time when waiting for a rwlock. The following patch >> series re-enables irqs while waiting for the lock, resembling the code >> which is already there for spinlocks. > > Perhaps I'm just out in left field, but that (and the similar behaviour > for obtaining a spinlock?) feels like treating a symptom rather than a > root cause where the root cause would appear to be long lock hold > times/contention? Sometimes lock contention on large systems will take a few seconds to pass. This is normal behavior which simply can not be eliminated. For those cases, we need to rely upon being able to re-enable interrupts and allowing other operations to continue normally. Simply put, in some cases, nothing more can be done. Thanks, Robin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists