From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53767C48BD5 for ; Tue, 25 Jun 2019 11:19:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 25EC8213F2 for ; Tue, 25 Jun 2019 11:19:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730468AbfFYLTH (ORCPT ); Tue, 25 Jun 2019 07:19:07 -0400 Received: from mx2.suse.de ([195.135.220.15]:51812 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730461AbfFYLTH (ORCPT ); Tue, 25 Jun 2019 07:19:07 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id AD39FAEFF; Tue, 25 Jun 2019 11:19:05 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 25 Jun 2019 13:19:04 +0200 From: Roman Penyaev To: Linus Torvalds Cc: Andrew Morton , Al Viro , Peter Zijlstra , Azat Khuzhin , Eric Wong , linux-fsdevel , Linux List Kernel Mailing Subject: Re: [PATCH v5 00/14] epoll: support pollable epoll from userspace In-Reply-To: References: <20190624144151.22688-1-rpenyaev@suse.de> Message-ID: X-Sender: rpenyaev@suse.de User-Agent: Roundcube Webmail Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On 2019-06-24 22:38, Linus Torvalds wrote: > On Mon, Jun 24, 2019 at 10:42 PM Roman Penyaev > wrote: >> >> So harvesting events from userspace gives 15% gain. Though bench_http >> is not ideal benchmark, but at least it is the part of libevent and >> was >> easy to modify. >> >> Worth to mention that uepoll is very sensible to CPU, e.g. the gain >> above >> is observed on desktop "Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz", >> but on >> "Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz" measurements are almost >> the >> same for both runs. > > Hmm. 15% may be big in a big picture thing, but when it comes to what > is pretty much a micro-benchmark, I'm not sure how meaningful it is. > > And the CPU sensitivity thing worries me. Did you check _why_ it > doesn't seem to make any difference on the Xeon 4110? Is it just > because at that point the machine has enough cores that you might as > well just sit in epoll() in the kernel and uepoll doesn't give you > much? Or is there something else going on? This http tool is a singlethreaded test, i.e. client and server work as a standalone processes and each has a single event thread for everything. According to what I saw there, is that events come slowly (or event loop acts faster?), so when time has come to harvest events there is nothing, we take a slow path and go to kernel in order to sleep. That does not explain the main "why", unfortunately. I would like to retest that adding more clients to the server, thus server is more likely to observe events in a ring, avoiding sleep. -- Roman