On Saturday, August 24, 2013 10:16:33 am Robert Watson wrote:
There are a number of other places in the kernel where migration to an rmlock
makes sense -- however, some care must be taken for four reasons: (1) while
read locks don't experience line contention, write locking becomes observably
On Thursday, August 29, 2013 11:37:08 am Scott Long wrote:
On Aug 29, 2013, at 7:42 AM, John Baldwin j...@freebsd.org wrote:
On Saturday, August 24, 2013 10:16:33 am Robert Watson wrote:
There are a number of other places in the kernel where migration to an
rmlock
makes sense --
On Aug 29, 2013, at 7:42 AM, John Baldwin j...@freebsd.org wrote:
On Saturday, August 24, 2013 10:16:33 am Robert Watson wrote:
There are a number of other places in the kernel where migration to an
rmlock
makes sense -- however, some care must be taken for four reasons: (1) while
read
On Sat, Aug 24, 2013 at 7:16 AM, Robert Watson rwat...@freebsd.org wrote:
On Sat, 24 Aug 2013, Alexander V. Chernikov wrote:
On 24.08.2013 00:54, Adrian Chadd wrote:
I'd like to commit this to -10. It migrates the if_lagg locking
from a rw lock to a rm lock. We see a bit of contention
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24.08.2013 00:54, Adrian Chadd wrote:
Hi,
I'd like to commit this to -10. It migrates the if_lagg locking
from a rw lock to a rm lock. We see a bit of contention between the
transmit and
We're running lagg with rmlock on several hundred
On Sat, 24 Aug 2013, Alexander V. Chernikov wrote:
On 24.08.2013 00:54, Adrian Chadd wrote:
I'd like to commit this to -10. It migrates the if_lagg locking
from a rw lock to a rm lock. We see a bit of contention between the
transmit and
We're running lagg with rmlock on several hundred
Sorry, I meant line contention rather than lock contention. Yes, you're
right.
-adrian
On 24 August 2013 07:16, Robert Watson rwat...@freebsd.org wrote:
On Sat, 24 Aug 2013, Alexander V. Chernikov wrote:
On 24.08.2013 00:54, Adrian Chadd wrote:
I'd like to commit this to -10. It
On 8/24/13 7:16 AM, Robert Watson wrote:
On Sat, 24 Aug 2013, Alexander V. Chernikov wrote:
On 24.08.2013 00:54, Adrian Chadd wrote:
I'd like to commit this to -10. It migrates the if_lagg locking
from a rw lock to a rm lock. We see a bit of contention between the
transmit and
We're
On 24 Aug 2013, at 17:36, Alfred Perlstein wrote:
We should distinguish lock contention from line contention. When
acquiring a rwlock on multiple CPUs concurrently, the cache lines used to
implement the lock are contended, as they must bounce between caches via the
cache coherence
On 8/24/13 10:47 AM, Robert N. M. Watson wrote:
On 24 Aug 2013, at 17:36, Alfred Perlstein wrote:
We should distinguish lock contention from line contention. When acquiring a rwlock
on multiple CPUs concurrently, the cache lines used to implement the lock are contended, as they must bounce
Hihi,
There's two parts to my patch:
* one is migrating the rwlock to rmlock - not because of counters, but
because the lock is protecting consistency when changing the lagg config
* one is adding a new lock specifically to ensure that the callout is
atomically created/called/destroyed
The
On Aug 24, 2013, at 12:14 PM, Alfred Perlstein bri...@mu.org wrote:
On 8/24/13 10:47 AM, Robert N. M. Watson wrote:
On 24 Aug 2013, at 17:36, Alfred Perlstein wrote:
We should distinguish lock contention from line contention. When
acquiring a rwlock on multiple CPUs concurrently, the
Hi,
I'd like to commit this to -10. It migrates the if_lagg locking from a rw
lock to a rm lock. We see a bit of contention between the transmit and
receive sides of lagg during traffic loads (10+ gigabit per second.) Using
rmlocks eliminate this.
13 matches
Mail list logo
