From: Kirill Tkhai <ktkhai@virtuozzo.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: kuznet@virtuozzo.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] fuse: Use hash table to link processing request
Date: Tue, 25 Sep 2018 12:35:23 +0300 [thread overview]
Message-ID: <00ffd41c-b28c-466a-c496-546ce57d7990@virtuozzo.com> (raw)
In-Reply-To: <CAJfpegt3ckxAUAdabXKwxgFYdP9=wVSis+G3pztWgqzXVGNFSA@mail.gmail.com>
On 25.09.2018 12:08, Miklos Szeredi wrote:
> On Tue, Sep 11, 2018 at 12:12 PM, Kirill Tkhai <ktkhai@virtuozzo.com> 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
next prev parent reply other threads:[~2018-09-25 15:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-11 10:11 [PATCH 0/3] fuse: Solve request_find() bottleneck Kirill Tkhai
2018-09-11 10:11 ` [PATCH 1/3] fuse: Change interrupt requests allocation algorhythm Kirill Tkhai
2018-09-11 10:12 ` [PATCH 2/3] fuse: Kill fuse_req::intr_unique Kirill Tkhai
2018-09-11 10:12 ` [PATCH 3/3] fuse: Use hash table to link processing request Kirill Tkhai
2018-09-25 9:08 ` Miklos Szeredi
2018-09-25 9:35 ` Kirill Tkhai [this message]
2018-09-24 12:08 ` [PATCH 0/3] fuse: Solve request_find() bottleneck Kirill Tkhai
2018-09-24 15:04 ` Miklos Szeredi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=00ffd41c-b28c-466a-c496-546ce57d7990@virtuozzo.com \
--to=ktkhai@virtuozzo.com \
--cc=kuznet@virtuozzo.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).