From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752425AbdJDO6j (ORCPT ); Wed, 4 Oct 2017 10:58:39 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:33127 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752242AbdJDO6i (ORCPT ); Wed, 4 Oct 2017 10:58:38 -0400 Date: Wed, 4 Oct 2017 07:58:35 -0700 From: Matthew Wilcox To: Eric Dumazet Cc: Mateusz Guzik , Al Viro , mszeredi@redhat.com, linux-fsdevel@vger.kernel.org, LKML Subject: Re: [PATCH 2/2] vfs: grab the lock instead of blocking in __fd_install during resizing Message-ID: <20171004145835.GB22253@bombadil.infradead.org> References: <1507028295-9353-1-git-send-email-mguzik@redhat.com> <1507028295-9353-3-git-send-email-mguzik@redhat.com> <20171004135541.GA22253@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 04, 2017 at 07:00:40AM -0700, Eric Dumazet wrote: > On Wed, Oct 4, 2017 at 6:55 AM, Matthew Wilcox wrote: > > Any chance you could review the patches from Sandhya that make this entire > > codepath obsolete? > > > > https://lkml.org/lkml/2017/4/29/20 > > > > Hmm... > > 18 files changed, 578 insertions(+), 585 deletions(-) > > Frankly I need to be convinced with solid performance numbers before I > am taking a look at this series. I was hoping you'd help us get some solid performance numbers ... you seem to have workloads available to you that help find weaknesses in implementations. The number of lines inserted is a bit of a red herring. Over 100 are in the test suite (you surely aren't going to review those) and another ~300 are adding enhancements to the IDR & radix tree that should be useful for other users (eg I think I have a way to speed up writing out dirty pages by using get_tag_batch()). > I do not believe an IDR will be faster than current implementation, so > I am not quite convinced at this moment. I don't think it should be significantly different in performance. Let's look at the layout of data for a typical bash shell (fds 0-2 and 255 open). Current implementation: files_struct -> fdt -> fd -> struct file IDR: files_struct -> radix node (shift 6) -> radix node (shift 0) -> struct file In either case, it's the same number of dependent loads. It'll start to look worse for the radix tree above 4096 open fds in a given process.