Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp651476ybm; Tue, 21 May 2019 00:53:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqwe0Z9XK/T9M2Ko2SRaRSWZde8/hHpiLGHTWhygPH+dySWBiZL/xj+hVZdddERvP6dosW8m X-Received: by 2002:a63:700b:: with SMTP id l11mr24681642pgc.449.1558425197911; Tue, 21 May 2019 00:53:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558425197; cv=none; d=google.com; s=arc-20160816; b=Xyauz8lph2d/eyxtpGr+IBOu5CnBeHGJOcshkm6OrIrE1J+Ko/fji3hKEdvANbddZi AcTmVyjIEHacuBPDJkuGuI2QpVhMn7PNYeHfdnjTJvf9wkDhC6VLXgOAwMrGFtruowCz XcmBa3omX3u/Yr/t4ZlOi5wx7u13k0d2scBb1+nyb1/YwyfjHFrDSm8nTtrzUYiOk88E +EzeMMzpCJtHJnOAO8FIdVlsdQ5uaiCtvhbQRylJqElv5YHApwD5Yiw0js2Bdv8p5V6f Sk74794YBfMfxZSXHgLM+PuahCBviJUGzSFeE+90VzWqL+fOm6Yu/Lc0EZHSB1NIN5m5 9zrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=ZXMoCZCIsX8UyNK8ZVr+b8XASVXeJBJq2OtK7BChG90=; b=Xc7TyckiTJXIc1A/9wvYJx9cLplWxnFb/dgktNRooJHBKPhGhj/Sw/NR7iDtdUVbtX ptiNfP8VIuKksuop/bLL4IuBJqmZVFruWtVthL7jsX1qCWJGHuNJrA9JrgIQZaZXS1go OZOiRgWLSm0PfU9F/C6ItQDY0aPRWOIuk3IElD/LgUfH1NfYEtrvJOq1IpCN5hsSZPnF AIY6Ta4UZp5jjgUc65Jq6qH/RvcygtHe6EqYspxm46BdfRCAxPyEi4+05qeFseCrK6DW uG6cHv7WaKmz8nhfiU1NH6mLy0d18DYlTCrRhUGli4f4KNszToGrDpqGLp8RhEnN1FCW YATg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i98si20628062plb.104.2019.05.21.00.53.03; Tue, 21 May 2019 00:53:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727074AbfEUHvP (ORCPT + 99 others); Tue, 21 May 2019 03:51:15 -0400 Received: from dcvr.yhbt.net ([64.71.152.64]:35804 "EHLO dcvr.yhbt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725790AbfEUHvP (ORCPT ); Tue, 21 May 2019 03:51:15 -0400 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id ABD7C1F462; Tue, 21 May 2019 07:51:14 +0000 (UTC) Date: Tue, 21 May 2019 07:51:14 +0000 From: Eric Wong To: Roman Penyaev Cc: Azat Khuzhin , Andrew Morton , Al Viro , Linus Torvalds , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 05/13] epoll: offload polling to a work in case of epfd polled from userspace Message-ID: <20190521075114.if4urjezominbojj@dcvr> References: <20190516085810.31077-1-rpenyaev@suse.de> <20190516085810.31077-6-rpenyaev@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190516085810.31077-6-rpenyaev@suse.de> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Roman Penyaev wrote: > diff --git a/fs/eventpoll.c b/fs/eventpoll.c > index 81da4571f1e0..9d3905c0afbf 100644 > --- a/fs/eventpoll.c > +++ b/fs/eventpoll.c > @@ -44,6 +44,7 @@ > #include > #include > #include > +#include > #include > > /* > @@ -185,6 +186,9 @@ struct epitem { > > /* The structure that describe the interested events and the source fd */ > struct epoll_event event; > + > + /* Work for offloading event callback */ > + struct work_struct work; > }; > > /* Can we avoid the size regression for existing epoll users? > @@ -2547,12 +2601,6 @@ static int __init eventpoll_init(void) > ep_nested_calls_init(&poll_safewake_ncalls); > #endif > > - /* > - * We can have many thousands of epitems, so prevent this from > - * using an extra cache line on 64-bit (and smaller) CPUs > - */ > - BUILD_BUG_ON(sizeof(void *) <= 8 && sizeof(struct epitem) > 128); > - > /* Allocates slab cache used to allocate "struct epitem" items */ > epi_cache = kmem_cache_create("eventpoll_epi", sizeof(struct epitem), > 0, SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT, NULL); Perhaps a "struct uepitem" transparent union and separate slab cache.