From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933219AbdGSWuy (ORCPT ); Wed, 19 Jul 2017 18:50:54 -0400 Received: from mx2.suse.de ([195.135.220.15]:39871 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932268AbdGSWux (ORCPT ); Wed, 19 Jul 2017 18:50:53 -0400 Date: Wed, 19 Jul 2017 15:50:39 -0700 From: Davidlohr Bueso To: Jan Kara Cc: akpm@linux-foundation.org, mingo@kernel.org, peterz@infradead.org, torvalds@linux-foundation.org, kirill.shutemov@linux.intel.com, hch@infradead.org, ldufour@linux.vnet.ibm.com, mhocko@suse.com, mgorman@techsingularity.net, linux-kernel@vger.kernel.org, tytso@mit.edu, Davidlohr Bueso Subject: Re: [PATCH 15/17] fs/ext4: use cached rbtrees Message-ID: <20170719225039.GC14395@linux-80c1.suse> References: <20170719014603.19029-1-dave@stgolabs.net> <20170719014603.19029-16-dave@stgolabs.net> <20170719074056.GA12546@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20170719074056.GA12546@quack2.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 19 Jul 2017, Jan Kara wrote: >Hum, so I'm somewhat undecided whether this is worth the churn. For free >blocks rb_tree we use rb_first() only in ext4_mb_generate_from_freelist() >which gets called only when generating new buddy bitmap from on-disk bitmap >and we traverse the whole tree after that - thus the extra cost of >rb_first() is a) well hidden in the total cost of iteration, b) rather rare >anyway. Yes, during some of the testing I did for this patch, I could not find trees with more than just a handful of nodes, ie: while removing file(s). > >Similarly for the H-tree directory code, we call rb_first() in >ext4_dx_readdir() only to start an iteration over the whole B-tree and in >such case I don't think optimizing rb_first() makes a big difference >(maintaining cached value is going to have about the same cost as we save >by using it). Your reaction is rather expected, actually. Lets just leave this patch out. Thanks, Davidlohr