Implement parallel dbuf eviction #16487
Conversation
allanjude
force-pushed
the
parallel_dbuf_evict
branch
from
d3aad0f
to
3570e89
Compare
allanjude
force-pushed
the
parallel_dbuf_evict
branch
from
3570e89
to
5b070d1
Compare
| if (skip == 0) | ||
| skip = 1; |
| */ | ||
| static void | ||
| dbuf_evict_one(void) | ||
| dbuf_evict_many(uint64_t bytes, unsigned int idx) |
There was a problem hiding this comment.
I would change the arguments order.
| uint64_t nchunks = ((bytes - 1) >> DBUF_MIN_EVICT_PERTASK_SHIFT) + 1; | ||
| unsigned n = nchunks < num_sublists ? nchunks : num_sublists; | ||
| uint64_t fullrows = nchunks / n; | ||
| unsigned lastrowcols = nchunks % n; | ||
| unsigned k = (lastrowcols ? lastrowcols : n); | ||
|
|
||
| uint64_t bytes_pertask_low = fullrows << DBUF_MIN_EVICT_PERTASK_SHIFT; | ||
| uint64_t bytes_pertask = bytes_pertask_low + (lastrowcols ? | ||
| (1 << DBUF_MIN_EVICT_PERTASK_SHIFT) : 0); |
There was a problem hiding this comment.
Same as for ARC seems over-engineered. No need for tasks to be multiple of 1 << DBUF_MIN_EVICT_PERTASK_SHIFT.
| evarg[i].idx = idx; | ||
| evarg[i].bytes = evict; | ||
|
|
||
| taskq_dispatch_ent(dbuf_evict_taskq, dbuf_evict_task, | ||
| &evarg[i], 0, &evarg[i].tqe); |
There was a problem hiding this comment.
Somewhere here should be taskq_init_ent(), probably.
| if (size > dbuf_cache_target_bytes()) { | ||
| if (size > dbuf_cache_hiwater_bytes()) | ||
| dbuf_evict_one(); | ||
| dbuf_evict(); |
There was a problem hiding this comment.
Lets assume we have 10 user threads calling this. I suppose each of them will try to create own task sets to evict the same full amount of extra dbuf caches using all the same CPUs. In best case it may end up with empty dbuf cache. I am not sure I greatly like the design of one main eviction thread calling bunch of other taskqs, but each client thread doing that definitely looks weird. I think if user threads has to do evictions, they should do it directly, just doing more than one buffer at a time to be more efficient, as you have said.
0mp
force-pushed
the
parallel_dbuf_evict
branch
2 times, most recently
from
d4a8574
to
54888d8
Compare
In the previous code, dbuf_evict_thread() would called dbuf_evict_one() in a look while dbuf_cache_above_lowater(). dbuf_evict_one() would select a random sublist from the dbuf cache, then walk it from the tail forward, attempting to acquire the lock on each object until it succeeded, then evict that object and return. As the name suggests, it would evict only a single object from the cache. However, evicting one object is not likely to bring us below the desired low water mark, so dbuf_evict_one() will be called again, where it will loop over all of the same busy objects again, until it founds one it can evict. This has been replaced with dbuf_evict_many() which takes a specific sublist as a parameter, as well as a desired amount of data to evict. It then walks the sublist from the tail forward, evicting what it can until the number of bytes evicted satisfies the input parameter or the head of the sublist is reached. The dbuf_evict_thread now runs is parallel as well, allowing it to keep up with demand more easily. For the dbuf cache, if the single thread was not able to keep up, ZFS would shift the work of evicting some items to each incoming I/O thread. While that is still the case it should be seen much less often now that dbuf_evict is more efficient and no longer bottlenecked to a single thread. Sponsored-by: Expensify, Inc. Sponsored-by: Klara, Inc. Co-authored-by: Allan Jude <[email protected]> Co-authored-by: Mateusz Piotrowski <[email protected]> Signed-off-by: Alexander Stetsenko <[email protected]> Signed-off-by: Allan Jude <[email protected]> Signed-off-by: Mateusz Piotrowski <[email protected]>
0mp
force-pushed
the
parallel_dbuf_evict
branch
from
54888d8
to
883cd30
Compare
|
I have updated the patch with a different logic for picking the default maximum number of dbuf eviction threads. The new logic aims to pick the number that is one-eighth of the available CPUs, with a minimum of 2 and a maximum of 16. |
Sponsored-by: Expensify, Inc.
Sponsored-by: Klara, Inc.
Motivation and Context
Replace
dbuf_evict_one()withdbuf_evict_many()to more efficiently evict dbuf objects without looping over the same locked objects over and over.Description
In the previous code, dbuf_evict_thread() would called dbuf_evict_one() in a look while dbuf_cache_above_lowater().
dbuf_evict_one() would select a random sublist from the dbuf cache, then walk it from the tail forward, attempting to acquire the lock on each object until it succeeded, then evict that object and return.
As the name suggests, it would evict only a single object from the cache. However, evicting one object is not likely to bring us below the desired low water mark, so dbuf_evict_one() will be called again, where it will loop over all of the same busy objects again, until it founds one it can evict.
This has been replaced with dbuf_evict_many() which takes a specific sublist as a parameter, as well as a desired amount of data to evict. It then walks the sublist from the tail forward, evicting what it can until the number of bytes evicted satisfies the input parameter or the head of the sublist is reached.
The dbuf_evict_thread now runs is parallel as well, allowing it to keep up with demand more easily. For the dbuf cache, if the single thread was not able to keep up, ZFS would shift the work of evicting some items to each incoming I/O thread. While that is still the case it should be seen much less often now that dbuf_evict is more efficient and no longer bottlenecked to a single thread.
How Has This Been Tested?
Performance benchmarks while the dbuf cache is full
Types of changes
Checklist:
Signed-off-by.