On Wed, 3 Aug 2016, Michal Hocko wrote:
> > > Even mempool allocations shouldn't allow reclaim to > > > scan pages too quickly even when LRU lists are full of dirty pages. But > > > as I've said that would restrict the success rates even under light page > > > cache load. Throttling on the wait_iff_congested should be quite rare. > > > > > > Anyway do you see an excessive throttling with the patch posted > > > http://lkml.kernel.org/r/[email protected] ? Or from > > > > It didn't have much effect. > > > > Since the patch 4e390b2b2f34b8daaabf2df1df0cf8f798b87ddb (revert of the > > limitless mempool allocations), swapping to dm-crypt works in the simple > > example. > > OK. Do you see any throttling due to wait_iff_congested? No, but I've seen occasional stalls of mempool allocations in throttle_vm_writeout - but the patch that removed throttle_vm_writeout didn't improve overall speed, so the stalls were only minor. > writeback_wait_iff_congested trace point should help here. If not maybe > we should start with the above patch and see how it works in practise. > If the there is still an excessive and unexpected throttling then we > should move on to a more mempool/block layer users specific solution. Currently, dm-crypt reports the device congested only if the underlying block device is congested. But as others suggested, dm-crypt should report congested status if is clogged due to slow encryption progress - and in that case you should not throttle mempool allocations (because such throttling would decrease encryption speed even more). Mikulas > -- > Michal Hocko > SUSE Labs
