From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965183AbbKCXNq (ORCPT ); Tue, 3 Nov 2015 18:13:46 -0500 Received: from mail-wi0-f180.google.com ([209.85.212.180]:34086 "EHLO mail-wi0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965132AbbKCXNo (ORCPT ); Tue, 3 Nov 2015 18:13:44 -0500 From: Rasmus Villemoes To: Linus Torvalds Cc: Alexander Viro , linux-fsdevel , Linux Kernel Mailing List Subject: Re: [RFC] vfs: don't bother clearing close_on_exec bit for unused fds Organization: D03 References: <1446543679-28849-1-git-send-email-linux@rasmusvillemoes.dk> X-Hashcash: 1:20:151103:linux-fsdevel@vger.kernel.org::T3EXTEskfFPn7btO:0000000000000000000000000000000021Vl X-Hashcash: 1:20:151103:linux-kernel@vger.kernel.org::yr07aeHKmZ3R59/D:0000000000000000000000000000000004zee X-Hashcash: 1:20:151103:torvalds@linux-foundation.org::KWVMhk/KYACXbLke:000000000000000000000000000000006Bai X-Hashcash: 1:20:151103:viro@zeniv.linux.org.uk::MY1vZmOFge4rs1TZ:000000000000000000000000000000000000009X2I Date: Wed, 04 Nov 2015 00:13:41 +0100 In-Reply-To: (Linus Torvalds's message of "Tue, 3 Nov 2015 14:45:01 -0800") Message-ID: <878u6ed6ca.fsf@rasmusvillemoes.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 03 2015, Linus Torvalds wrote: > On Tue, Nov 3, 2015 at 1:41 AM, Rasmus Villemoes > wrote: >> >> I'm sure I've missed something, hence the RFC. But if not, there's >> probably also a few memsets which become redundant. And the >> __set_close_on_exec part should probably be its own patch... > > The patch looks fine to me. I'm not sure the __set_close_on_exec part > even makes sense, because if you set that bit, it usually really *is* > clear before, so testing it beforehand is just pointless. And if > somebody really keeps setting the bit, they are doing something stupid > anyway.. So that's true for the lifetime of a single fd where no-one of course does fcntl(fd, FD_CLOEXEC) more than once. But the scenario I was thinking of was when fds get recycled. open(, O_CLOEXEC) => 5, close(5), open(, O_CLOEXEC) => 5; in that case, letting the close_on_exec bit keep its value avoids dirtying the cache line on all subsequent allocations of fd 5 (for example, had Eric's app been using *_CLOEXEC for all its open's, socket's etc. there wouldn't have been any gain by adding the conditional to __clear_close_on_exec, but I'd expect to see a similar gain by doing the symmetric thing). Again, this is assuming that almost all fd allocations either do or do not apply CLOEXEC - after a while, ->close_on_exec would reach a steady-state where no bits get flipped anymore. The "usually really *is* clear" only holds when we do "bother clearing close_on_exec bit for unused fds", which is what I suggest we don't :-) I don't think either state of the bit in close_on_exec is more or less 'up-to-date' when its buddy in open_fds is not set. Rasmus