On Fri 23-04-21 19:39:09, Zhang Yi wrote:

On 2021/4/22 17:04, Jan Kara wrote:

quoted

I'm OK with that because mainly for IO error reporting it makes sense to
me. For this memory reclaim problem I think we have also other reasonably
sensible options. E.g. we could have a shrinker that would just walk the
checkpoint list and reclaim journal heads for whatever is already written
out... Or we could just release journal heads already after commit and
during checkpoint we'd fetch the list of blocks that may need to be written
out e.g. from journal descriptor blocks. This would be a larger overhaul
but as a bonus we'd get rid of probably the last place in the kernel which
can write out page contents through buffer heads without updating page
state properly (and thus get rid of some workarounds in mm code as well).

Thanks for these suggestions, I get your first solution and sounds good, but
I do not understand your last sentence, how does ext4 not updating page state
properly? Could you explain it more clearly?

The problem with current checkpointing code is that it writes out dirty
buffer heads through submit_bh() function without updating page dirty state
or without setting PageWriteback bit (because we cannot easily grab page
lock in those places due to lock ordering). Thus we can end up with a page
that is dirty but in fact does not hold any dirty data (none of the buffer
heads is dirty) and also locking a page and checking for PageWriteback
isn't enough to be sure page is not under IO. This is ugly and requires
some workarounds in MM code...

								Honza
-- 
Jan Kara [off-list ref]
SUSE Labs, CR