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=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 3D35FC4742C for ; Mon, 2 Nov 2020 18:51:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7E7652225E for ; Mon, 2 Nov 2020 18:51:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="Y/TBlS1e" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7E7652225E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BCAEA6B0036; Mon, 2 Nov 2020 13:51:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B86D96B005C; Mon, 2 Nov 2020 13:51:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A19036B0068; Mon, 2 Nov 2020 13:51:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0207.hostedemail.com [216.40.44.207]) by kanga.kvack.org (Postfix) with ESMTP id 6990B6B0036 for ; Mon, 2 Nov 2020 13:51:43 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 0DD5C181AC9CC for ; Mon, 2 Nov 2020 18:51:43 +0000 (UTC) X-FDA: 77440372086.24.cakes56_0709ec2272b2 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin24.hostedemail.com (Postfix) with ESMTP id D34051A4AA for ; Mon, 2 Nov 2020 18:51:42 +0000 (UTC) X-HE-Tag: cakes56_0709ec2272b2 X-Filterd-Recvd-Size: 5463 Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Mon, 2 Nov 2020 18:51:42 +0000 (UTC) Received: by mail-lf1-f65.google.com with SMTP id y184so16814918lfa.12 for ; Mon, 02 Nov 2020 10:51:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Il1RVRiUKAxoef5RnNd4syWE0WLl3orYpLwRBHqOz80=; b=Y/TBlS1eFyfbbSotePutJHXTGFVPAS+8IcR03nDZGR1K5euC5et7jo1unYNqTUbp3U BjqqnZAVvs3BOTVNA0F6VNGSfKnRNlF9V4E4/vPDQFUhmAnDPA3qkxPcbFI9fnkBwHhB oDvidamVan9jWztUM4FhGTo0zmOUS68WBJoAk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Il1RVRiUKAxoef5RnNd4syWE0WLl3orYpLwRBHqOz80=; b=UykbbmevVSE33EJf85acUKOR21mDQCVWZ4ZW8KgVHRD+p+vbmfACbIDTygugoBHROi JH0NDUHn8Qh7VpjsOM/2MIA+gBdylIDybi8WFYCU7q/Ao2pyxyc9bUfEU+bWd48xGywO irNR+RBfZgzpQfKjI2r+FC95ez9Rcsie3exxXGJUNVf54Kd1vwU2S43V4TTTmBsLr9sp ZJaOTkQ7qOlAukzvbUi2MdtPxJ/lTkKNVmb7oRCZyJ8nMQykZpnfSRm6Cd65hgPk3l91 e91oQH/oRRsSc1xCGVvycYsw0uUVFtugVItKuPrFbls9EhksjoLmA1IsuHKLmhqol9uU LL3A== X-Gm-Message-State: AOAM531WQ4XOrBNgkp0/OcGhxzGHD92rTE76rJrATulvQUcSS/9vvK4v sXag3oztzJ6TeiRzPN/d20EKcFaqMtonZg== X-Google-Smtp-Source: ABdhPJxXEC42yYGXoUQHUKZFwJctK0WBuOxWVFYv2osWYbid8DfCaXVj1DmtNqZdmuuLenBusWF9OQ== X-Received: by 2002:a19:a11:: with SMTP id 17mr5895642lfk.240.1604343099877; Mon, 02 Nov 2020 10:51:39 -0800 (PST) Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com. [209.85.167.52]) by smtp.gmail.com with ESMTPSA id l9sm2875249ljc.86.2020.11.02.10.51.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Nov 2020 10:51:36 -0800 (PST) Received: by mail-lf1-f52.google.com with SMTP id f9so18796974lfq.2 for ; Mon, 02 Nov 2020 10:51:35 -0800 (PST) X-Received: by 2002:a19:7518:: with SMTP id y24mr3195355lfe.133.1604343095295; Mon, 02 Nov 2020 10:51:35 -0800 (PST) MIME-Version: 1.0 References: <20201101170656.48abbd5e88375219f868af5e@linux-foundation.org> <20201102010804.uENOQsZO9%akpm@linux-foundation.org> In-Reply-To: From: Linus Torvalds Date: Mon, 2 Nov 2020 10:51:19 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 13/15] epoll: check ep_events_available() upon timeout To: Soheil Hassas Yeganeh Cc: Andrew Morton , Davidlohr Bueso , Eric Dumazet , Guantao Liu , Khazhismel Kumykov , Linux-MM , mm-commits@vger.kernel.org, Al Viro , Willem de Bruijn Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Nov 2, 2020 at 9:49 AM Soheil Hassas Yeganeh wrote: > > Thank you for the suggestion. That was the first version I tried, and > I can confirm it fixes the race because we call ep_send_events() once > more before returning. Though, I believe, due to time_out=1, we won't > goto fetch_events to call ep_events_available(): > > if (!res && eavail && > !(res = ep_send_events(ep, events, maxevents)) && !timed_out) > goto fetch_events; Right. We won't be repeating the loop, but we will do one final send_events. Which I think is really the point, no? > You're spot on that the patch is more complicated than your > suggestion. However, the downside I observed was a performance > regression for the non-racy case: Suppose there are a few threads with > a similar non-zero timeout and no ready event. They will all > experience a noticeable contention in ep_scan_ready_list, by > unconditionally calling ep_send_events(). The contention was large > because there will be 2 write locks on ep->lock and one mutex lock on > ep->mtx with a large critical section. Ugh. I really detest the eventpoll code. Afaik, it has no normal users anywhere, so it gets no real coverage except for the odd cases (presumably inside google?) A lot of the work over the last couple of years has been to try to simplify the code and streamline it, and fix bugs due to recursion. I really wish we would continue that pattern of trying to simplify this code rather than add more complexity on top of it, which is why I reacted to strongly to that patch. And that whole ep_poll() function is written in just about the most confusing way possible, with code that looks like loops but aren't ("while (0)") and goto's that _are_ loops ("goto fetch_events"). I'll go stare at it some more. Linus