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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180727144800.1065a3fd@xeon-e3>
Date:   Fri, 27 Jul 2018 14:48:00 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Saeed Mahameed <saeedm@...lanox.com>
Cc:     "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Gal Pressman <galp@...lanox.com>
Subject: Re: [net-next 04/13] net/mlx5e: Vxlan, replace spinlock with
 read-write lock

On Fri, 27 Jul 2018 14:15:09 -0700
Saeed Mahameed <saeedm@...lanox.com> wrote:

> From: Gal Pressman <galp@...lanox.com>
> 
> The VXLAN database is mainly used by readers in data path, and rarely
> used by control path writers.
> Multiple readers (threads) should not block each other and cause an
> unnecessary contention on the lock.
> 
> Replacing the spinlock with rwlock optimizes the common use case where
> adding ports to the table (adding VXLAN interfaces) is quite rare, but
> the table is accessed for each VXLAN TX skb.
> 
> Signed-off-by: Gal Pressman <galp@...lanox.com>
> Signed-off-by: Saeed Mahameed <saeedm@...lanox.com>

Did you know that for small sections a spinlock is significantly faster than
a reader-writer lock. It turns out that reader-writer locks the reader
creates a cache line bounce.

https://www.kernel.org/doc/Documentation/locking/spinlocks.txt


Lesson 2: reader-writer spinlocks.

If your data accesses have a very natural pattern where you usually tend
to mostly read from the shared variables, the reader-writer locks
(rw_lock) versions of the spinlocks are sometimes useful. They allow multiple
readers to be in the same critical region at once, but if somebody wants
to change the variables it has to get an exclusive write lock.

   NOTE! reader-writer locks require more atomic memory operations than
   simple spinlocks.  Unless the reader critical section is long, you
   are better off just using spinlocks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ