[<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