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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 17 Sep 2007 09:03:58 -0400
From:	jamal <>
To:	Evgeniy Polyakov <>
Cc:	David Miller <>,,,,
Subject: Re: [RFC][NET_SCHED] explict hold dev tx lock

On Mon, 2007-17-09 at 14:27 +0400, Evgeniy Polyakov wrote:

> How many cpu collisions you are seeing?

On 4 CPUs which were always transmitting very few - there was contention
in the range of 100 per million attempts.
Note: it doesnt matter that 4 cpus were busy, this lock is contended at
max (for all NAPI drivers i poked into) between two CPUs.

> Did I understand you right, that you replaced trylock with lock and
> thus removed collision handling and got better results?

Yes, a small one with the 4 CPUs and no irq binding. Note that in the
test cases i run, the contention for queue lock was high (since all CPUs
were busy processing traffic). 
I think as the the number of CPUs go up, this will become more
prominent. The choice is between contending for queue lock or this lock.
One lock is contended by max of two cpus, the other by N cpus. As N goes
up, you want to have more mercy on the one that is contended by N cpus.
Did that make sense?


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists