Received: by 10.192.165.148 with SMTP id m20csp905500imm; Wed, 25 Apr 2018 09:24:27 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+ajLpULCjUWlxMCj7muiS6VGi2vJO4FOCx8uJZG6Ne7M4r/7MCjKzt5o1lN5pxeViymOS2 X-Received: by 10.99.179.6 with SMTP id i6mr24209646pgf.434.1524673467452; Wed, 25 Apr 2018 09:24:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524673467; cv=none; d=google.com; s=arc-20160816; b=aFk5PdRpORNwSUF0Q3Tggi836buBzr2g7W3XJolsXGGw2Tz66mzneCHhS2wGjX6aQe +zKe6yXsg8TAHKvZxgjq7IUUqTOQo7O3ZLEuLvmG3LPot/cqDGI9P/14I37SNrYno7zG 3Rw9jZgj3m8elHM1sZOGIU1WEJ9SBdS6yRzWlYbUxCKiNrpg874ENsiaUFo997rf/mXa 0JLG4m1nHERG2xzDo9+JODcmtPFv5qZhXrRX1cBBEVY/jpa5/CeeVDj7SH0oqmT4DUFl +G2JjeFSXYcWIimD2rLtfX2IKCeS7ro8RPFP4vwZvjYB9RTXQomqGQTbFYEWmo8BB0cs x+XQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=FRjf1Dtxl0hu/dEpyu2P1s5d/1uO5IZXYxbTdc2SYXE=; b=lIVS2HqfV6YWiJVG0j4t0ZvYHWkZGdab3rZIG2lf39dcFGMBIfPP25tKtdCCPbpb54 EMf5Nnb20RUY6DWnpP1AaNxfe8RQYAnQojIghoRVrbh3GrLkjOD++tRP/PhAnc/4jnbm tOFs/GPenC+VhcwT160rtp+GQO1jg6DOcGAh8cNiIIJtJIZoPYtjhvPHqyO9irLRFcNF AKqa+xju5ddQ9zrBNb9WajYMbukveYQ25E8V+GmAgCgowWfJUxHxRpWLCv3nb8yuxsQD fHG458X36Yd/wwQjP5J+sTlef8l1aE/MhYtqWL1L3iV88Ygk5JVs6Kgu5uFhUU87x/dg cIOg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=hYnvho10; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y87si15941697pfi.141.2018.04.25.09.24.12; Wed, 25 Apr 2018 09:24:27 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=hYnvho10; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755960AbeDYQVO (ORCPT + 99 others); Wed, 25 Apr 2018 12:21:14 -0400 Received: from mail-pg0-f44.google.com ([74.125.83.44]:44401 "EHLO mail-pg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754839AbeDYQU6 (ORCPT ); Wed, 25 Apr 2018 12:20:58 -0400 Received: by mail-pg0-f44.google.com with SMTP id 82so3838616pge.11; Wed, 25 Apr 2018 09:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FRjf1Dtxl0hu/dEpyu2P1s5d/1uO5IZXYxbTdc2SYXE=; b=hYnvho10KEShxBtalfKZN5JwKa09ijo9wbliAiIBJzfhGcWjGsbFYjjsFZ73ApR+Uk ioMUIsgXSW4+32UhzC3BzAx8rrEWmVtZrSgjd1vKxiwaoZeUKiWiwr1cl/6QZSQvwBC2 z75M0sQz1NF/ALDvtAyCxbLQEB9c/5Ps7Pi05b/jtILZBJYfbcikNG5a4PL7ZiMQV8qF xDRqzmcW2qoMLVZoB/qXbnG40yjNluw3fnMucTbzpbNmZ9+LHcOI/BVDuZltIDRCOA+G p3bh017bRNydVSxuEtLdiHiFcrpnR3pblTzYo/XSvmofdnycHsB4BPQb7wyfuuvWf7FS ZqwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FRjf1Dtxl0hu/dEpyu2P1s5d/1uO5IZXYxbTdc2SYXE=; b=iWoa+CGmyVoRVozeoVD4ity3ur26q90VDuIKAs+M+aOBMEOiEDtC9cc+POHWSaDIAi vhaszsPG/BjM5AsVFP5mN470clJA9VKojCO0Kb9/7gi1PR5MiARa/I252B1ao+lxFYtU lQlPe34ZQcMCvvwNC6TKZlNmEi1UueMQAGmoFKZaLbd361WZHNjWXEYbCNnqqN7mQb30 y8T1LPhO2itaC3ZY0trGQ3lULJpmOMJhNly2hlek97dSsz+6EvTMobC6GFaZ4CZ/w19+ fFbLyLdgYHj2GkBI7B5n2AjnRu3C66Q95aawteq1g4YK1wIz1G2cKFsOYrenPPo4IFL9 aj4Q== X-Gm-Message-State: ALQs6tB/9EbR6k7vQ15pAwLxqypGanDto9xXmUfASUM8o/Hwk52LUfgZ 3JZ+RCfa+d6ZxXu5vOI8uww= X-Received: by 10.99.109.65 with SMTP id i62mr24104348pgc.233.1524673257890; Wed, 25 Apr 2018 09:20:57 -0700 (PDT) Received: from ?IPv6:2620:15c:2c1:200:55c7:81e6:c7d8:94b? ([2620:15c:2c1:200:55c7:81e6:c7d8:94b]) by smtp.gmail.com with ESMTPSA id t11sm30084998pgn.94.2018.04.25.09.20.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Apr 2018 09:20:57 -0700 (PDT) Subject: Re: [PATCH net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive To: Matthew Wilcox Cc: Christoph Hellwig , Eric Dumazet , "David S . Miller" , netdev , Andy Lutomirski , linux-kernel , linux-mm , Soheil Hassas Yeganeh References: <20180425052722.73022-1-edumazet@google.com> <20180425052722.73022-2-edumazet@google.com> <20180425062859.GA23914@infradead.org> <5cd31eba-63b5-9160-0a2e-f441340df0d3@gmail.com> <20180425160413.GC8546@bombadil.infradead.org> From: Eric Dumazet Message-ID: <8ce78bd6-8142-2937-11fd-2e4a2b22d90c@gmail.com> Date: Wed, 25 Apr 2018 09:20:55 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180425160413.GC8546@bombadil.infradead.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/25/2018 09:04 AM, Matthew Wilcox wrote: > If you don't zap the page range, any of the CPUs in the system where > any thread in this task have ever run may have a TLB entry pointing to > this page ... if the page is being recycled into the page allocator, > then that page might end up as a slab page or page table or page cache > while the other CPU still have access to it. Yes, this makes sense. > > You could hang onto the page until you've built up a sufficiently large > batch, then bulk-invalidate all of the TLB entries, but we start to get > into weirdnesses on different CPU architectures. > zap_page_range() is already doing a bulk-invalidate, so maybe vm_replace_page() wont bring serious improvement if we end-up doing same dance. Thanks.