On 10/04/2018 03:16 AM, Jan Kara wrote:
On Wed 12-09-18 15:28:52, Waiman Long wrote:
From: Davidlohr Bueso <dave@xxxxxxxxxxxx>So I was wondering: Is this really worth it? AFAICS we have a single call
Instead of the current O(N) implementation, at the cost
of adding an atomic counter, we can convert the call to
an atomic_read(). The counter only serves for accounting
empty to non-empty transitions, and vice versa; therefore
only modified twice for each of the lists during the
lifetime of the dlock (while used).
In addition, to be able to unaccount a list_del(), we
add a dlist pointer to each head, thus minimizing the
overall memory footprint.
Signed-off-by: Davidlohr Bueso <dbueso@xxxxxxx>
Acked-by: Waiman Long <longman@xxxxxxxxxx>
site for dlock_lists_empty() and that happens during umount where we don't
really care about this optimization. So it seems like unnecessary
complication to me at this point? If someone comes up with a usecase that
needs fast dlock_lists_empty(), then sure, we can do this...
Yes, that is true. We can skip this patch for the time being until a use
case comes up which requires dlock_lists_empty() to be used in the fast