From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754591AbbGBC2t (ORCPT ); Wed, 1 Jul 2015 22:28:49 -0400 Received: from mail-qg0-f53.google.com ([209.85.192.53]:33946 "EHLO mail-qg0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754095AbbGBC2q (ORCPT ); Wed, 1 Jul 2015 22:28:46 -0400 Date: Wed, 1 Jul 2015 22:28:43 -0400 From: Tejun Heo To: Jan Kara Cc: axboe@kernel.dk, linux-kernel@vger.kernel.org, hch@infradead.org, hannes@cmpxchg.org, linux-fsdevel@vger.kernel.org, vgoyal@redhat.com, lizefan@huawei.com, cgroups@vger.kernel.org, linux-mm@kvack.org, mhocko@suse.cz, clm@fb.com, fengguang.wu@intel.com, david@fromorbit.com, gthelen@google.com, khlebnikov@yandex-team.ru Subject: Re: [PATCH 39/51] writeback: make writeback_in_progress() take bdi_writeback instead of backing_dev_info Message-ID: <20150702022843.GI26440@mtj.duckdns.org> References: <1432329245-5844-1-git-send-email-tj@kernel.org> <1432329245-5844-40-git-send-email-tj@kernel.org> <20150701074708.GZ7252@quack.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150701074708.GZ7252@quack.suse.cz> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Jan. On Wed, Jul 01, 2015 at 09:47:08AM +0200, Jan Kara wrote: > BTW: It would have been easier for me to review this if e.g. a move from > bdi to wb parameter was split among less patches. The intermediate state > where some functions call partly bdi and party wb functions is strange and > it always makes me go search in the series whether the other part of the > function gets converted and whether they play well together... Similar argument. When reviewing big picture transitions, it *could* be easier to have larger lumps but I believe that's not necessarily because reviewing itself becomes easier but more because it becomes easier to skip what's uninteresting like actually verifying each change. Another aspect is that some of the changes are spread out. When each patch modifies one part, it's clear that all changes in the patch belong to that specific part; however, in larger lumps, there usually are a number of stragglers across the changes and associating them with other parts aren't necessarily trivial. This happens with patch descrption too. It becomes easier to slip in, intentionally or by mistake, unrelated changes without explaining what's going on. Thanks. -- tejun