On Mon, Jul 02, 2018 at 03:44:58PM +0800, Ethan Lien wrote: > We use customized, nodesize batch value to update dirty_metadata_bytes. > We should also use batch version of compare function or we will easily > goto fast path and get false result from percpu_counter_compare(). > > Signed-off-by: Ethan Lien <ethanlien@xxxxxxxxxxxx> This looks like it could have some observable effects. The default batch is 32 * cpus online, while the one supplied by btrfs is much higher as it's a multiple of nodesize. The BTRFS_DIRTY_METADATA_THRESH is 32MiB so the comparision is likely to be off scale in some if not most cases. I got lost in the callchains and how the return values of writepage are interpreted. The effect I see is: there are many pages batched (by the _add_batch calls) but none of the compare calls dects that and exits early. So there are more metadata being built up in memory and will have to be synced later. The change looks correct to me, we have to compare the numbers of the same units. I'll add it to misc-next for testing, maybe the 0day bot would detect some changes in performance. Please let me know if you have further insights or clarifications to what's written above, the changelog could use some update as the change has some unobvious consequences. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
