Re: [PATCH v2 2/4] sbitmap: remove swap_lock

2020-11-26 Thread Ming Lei
On Thu, Nov 26, 2020 at 01:44:36PM +, Pavel Begunkov wrote: > On 26/11/2020 02:46, Ming Lei wrote: > > On Sun, Nov 22, 2020 at 03:35:46PM +, Pavel Begunkov wrote: > >> map->swap_lock protects map->cleared from concurrent modification, > >> however sbitmap_deferred_clear() is already atomica

Re: [PATCH v2 2/4] sbitmap: remove swap_lock

2020-11-26 Thread Pavel Begunkov
On 26/11/2020 02:46, Ming Lei wrote: > On Sun, Nov 22, 2020 at 03:35:46PM +, Pavel Begunkov wrote: >> map->swap_lock protects map->cleared from concurrent modification, >> however sbitmap_deferred_clear() is already atomically drains it, so >> it's guaranteed to not loose bits on concurrent >>

Re: [PATCH v2 2/4] sbitmap: remove swap_lock

2020-11-25 Thread Ming Lei
On Sun, Nov 22, 2020 at 03:35:46PM +, Pavel Begunkov wrote: > map->swap_lock protects map->cleared from concurrent modification, > however sbitmap_deferred_clear() is already atomically drains it, so > it's guaranteed to not loose bits on concurrent > sbitmap_deferred_clear(). > > A one thread

Re: [PATCH v2 2/4] sbitmap: remove swap_lock

2020-11-24 Thread Pavel Begunkov
On 24/11/2020 14:22, John Garry wrote: > On 22/11/2020 15:35, Pavel Begunkov wrote: >> map->swap_lock protects map->cleared from concurrent modification, >> however sbitmap_deferred_clear() is already atomically drains it, so >> it's guaranteed to not loose bits on concurrent >> sbitmap_deferred_cl

Re: [PATCH v2 2/4] sbitmap: remove swap_lock

2020-11-24 Thread John Garry
On 22/11/2020 15:35, Pavel Begunkov wrote: map->swap_lock protects map->cleared from concurrent modification, however sbitmap_deferred_clear() is already atomically drains it, so it's guaranteed to not loose bits on concurrent sbitmap_deferred_clear(). A one threaded tag heavy test on top of nul

[PATCH v2 2/4] sbitmap: remove swap_lock

2020-11-22 Thread Pavel Begunkov
map->swap_lock protects map->cleared from concurrent modification, however sbitmap_deferred_clear() is already atomically drains it, so it's guaranteed to not loose bits on concurrent sbitmap_deferred_clear(). A one threaded tag heavy test on top of nullbk showed ~1.5% t-put increase, and 3% -> 1%