On Mon, Jun 17, 2019 at 04:37:16PM +0300, Nikolay Borisov wrote: > Prepare for refactoring and simplifying the code in __btrfs_map_block > by factoring out common code into a separete function - > btrfs_get_io_geometry. It perform necessary actions to map a > (logical addr, len) pair to the underlying physical disk. This code is > also necessary to figure if particular IO req will span a btrfs stripe, > to that effect __btrfs_map_block was called with bio_ret parameter set > to NULL as a way to indicate we only need the "mapping" logic and not > submit. > > Further it introduces a simple wrapper over its numerous return > parameters. Having multiple return params rather than a single struct > is a deliberate choice so as not to bloat the stack. > > Signed-off-by: Nikolay Borisov <nborisov@xxxxxxxx> This turns out a bit worse compared to the struct approach in v1. The stack stats for v2: __btrfs_map_block +64 (200 -> 264) NEW (152): btrfs_get_io_geometry btrfs_get_stripe_rem LOST/NEW DELTA: +152 PRE/POST DELTA: +216 >From the code prespective the struct is more readable than a series of NULL parameters. That would be justifiable in case the stack consumption would be dramatically better, but it's not. Thanks for the v2, I think this exercise was useful. I'm going to merge v1.
