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 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
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 24.08.2013 19:04, Adrian Chadd wrote:
I'm very close to starting an mbuf batching thing to use in a few places like
receive, transmit and
transmit completion -> free path. I'd be interested in your review/feedback and
testing as it sounds
like something you can easily stress test there. :)
Hello,
A friend of mine referred me to RFC-6994 on experimental TCP options, their
numering, the issues behind and a possible solution. Do we have support for
it? I don't see anything about it in the code.
http://www.rfc-editor.org/rfc/rfc6994.txt, Standard Track
Abstract
This document d
Hi!
Can you give us actual numbers? Something that we can easily graph?
Do you have a diff against -HEAD? I'd like to stare at it a bunch and think
about merging some stuff in. :-)
How are you testing it? Is it something I can set up in our lab and
thoroughly thrash?
I'm very close to starting
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 22.08.2013 00:51, Andre Oppermann wrote:
> On 19.08.2013 13:42, Alexander V. Chernikov wrote:
>> On 14.08.2013 19:48, Luigi Rizzo wrote:
>>> On Wed, Aug 14, 2013 at 05:40:28PM +0200, Marko Zec wrote:
On Wednesday 14 August 2013 14:40:24 Luigi R
-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
12 matches
Mail list logo
