Commit r345200 (new ARC reclamation threads) looks suspicious to me - second potential problem
Alexander Motin
mav at FreeBSD.org
Wed May 22 16:49:52 UTC 2019
On 22.05.2019 12:19, Slawa Olhovchenkov wrote:
> On Wed, May 22, 2019 at 12:07:29PM -0400, Alexander Motin wrote:
>
>> On 22.05.2019 11:50, Lev Serebryakov wrote:
>>> On 22.05.2019 18:19, Alexander Motin wrote:
>>>
>>>>>> But looks like `arc_kmem_reap_soon()` is synchronous on FreeBSD! So,
>>>>>> this `delay()` looks very wrong. Am I right?
>>>>
>>>> Why is it wrong?
>>> One second pause after synchronous operation to wait it completion?
>>
>> No. To rate-throttle them. This gives UMA a second to get back into
>> minimally steady state after we ripped all caches from it. As I have
>> told, we do not want to drain caches constantly in a tight loop, we want
>> more or less steady state.
>
> And also (posible) additionaly delay arc_get_data_impl().
arc_get_data_impl() depends on arc_adjust_zthr, not on arc_reap_zthr, so
it should not get blocked by this delay. That was the motivation for
the threads splitting in the last rewrite.
> This is incorrectly throttling implementation.
I am not particularly defending ZFS doing its own reclamation, I'd more
trust pagedaemon, but so far I haven't seen any memory pressure issues
after I committed this.
--
Alexander Motin
More information about the freebsd-hackers
mailing list