Thread (54 messages) 54 messages, 8 authors, 2016-11-28

Re: [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS_THROTTLE tasks

From: Michal Hocko <mhocko@kernel.org>
Date: 2016-07-25 19:23:56
Also in: dm-devel, lkml
Subsystem: memory management, memory management - mglru (multi-gen lru), memory management - reclaim, page cache, the rest · Maintainers: Andrew Morton, Johannes Weiner, Matthew Wilcox, Jan Kara, Linus Torvalds

[CC Marcelo who might remember other details for the loads which made
 him to add this code - see the patch changelog for more context]

On Mon 25-07-16 10:32:47, Michal Hocko wrote:
On Sat 23-07-16 10:12:24, NeilBrown wrote:
[...]
quoted
So I wonder what throttle_vm_writeout() really achieves these days.  Is
it just a bandaid that no-one is brave enough to remove?
Maybe yes. It is sitting there quietly and you do not know about it
until it bites. Like in this particular case.
So I was playing with this today and tried to provoke throttle_vm_writeout
and couldn't hit that path with my pretty much default IO stack. I
probably need a more complex IO setup like dm-crypt or something that
basically have to double buffer every page in the writeout for some
time.

Anyway I believe that the throttle_vm_writeout is just a relict from the
past which just survived after many other changes in the reclaim path. I
fully realize my testing is quite poor and I would really appreciate if
Mikulas could try to retest with his more complex IO setups but let me
post a patch with the changelog so that we can at least reason about the
justification. In principle the reclaim path should have sufficient
throttling already and if that is not the case then we should
consolidate the remaining rather than have yet another one.

Thoughts?
---
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help