On Aug 29, 2013, at 7:42 AM, John Baldwin 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 locks don
On Thursday, August 29, 2013 11:37:08 am Scott Long wrote:
>
> On Aug 29, 2013, at 7:42 AM, John Baldwin 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 -- howeve
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 observab
On Sat, Aug 24, 2013 at 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 t
On Aug 24, 2013, at 12:14 PM, Alfred Perlstein 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 c
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 latte
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
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 cohere
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 running
Sorry, I meant "line contention" rather than "lock contention". Yes, you're
right.
-adrian
On 24 August 2013 07:16, 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
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 heavi
-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 h
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.
http://people.freebsd.org/~adrian/netflix/2013081
13 matches
Mail list logo
