From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-eopbgr30101.outbound.protection.outlook.com ([40.107.3.101]:54389 "EHLO EUR03-AM5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726201AbeIYPmL (ORCPT ); Tue, 25 Sep 2018 11:42:11 -0400 Subject: Re: [PATCH 3/3] fuse: Use hash table to link processing request To: Miklos Szeredi Cc: kuznet@virtuozzo.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org References: <153666041612.19117.14667042009014596105.stgit@localhost.localdomain> <153666073461.19117.1958730317836145457.stgit@localhost.localdomain> From: Kirill Tkhai Message-ID: <00ffd41c-b28c-466a-c496-546ce57d7990@virtuozzo.com> Date: Tue, 25 Sep 2018 12:35:23 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 25.09.2018 12:08, Miklos Szeredi wrote: > On Tue, Sep 11, 2018 at 12:12 PM, Kirill Tkhai wrote: >> We noticed the performance bottle neck in FUSE running our >> Virtuozzo storage over rdma. On some types of workload >> we observe 20% of times pent in request_find() in profiler. >> This function is iterating over long requests list, and it >> scales bad. >> >> The patch introduces hash table to reduce the number >> of iterations, we do in this function. Hash generating >> algorithm is taken from hash_add() function, while >> 512 lines table is used to store pending requests. >> This fixes problem and improves the performance. > > Pushed to fuse.git#for-next with a number of small changes. E.g. I Thanks! > reduced the number of cachlines to 256 to make the hashtable size just > 4k. Was there a scientific reason for choosing 512 as the optimal > number of cache lines? I just tried to choose a size, which is not small for all of potential users. But, it looks like 256 should be also enough. So, there was no hidden mathematics... Kirill