From patchwork Tue Nov 3 09:41:19 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rasmus Villemoes X-Patchwork-Id: 7541101 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 921E59F6E4 for ; Tue, 3 Nov 2015 09:44:20 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B30CA209D6 for ; Tue, 3 Nov 2015 09:44:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CB757209D3 for ; Tue, 3 Nov 2015 09:44:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753181AbbKCJld (ORCPT ); Tue, 3 Nov 2015 04:41:33 -0500 Received: from mail-lf0-f52.google.com ([209.85.215.52]:34490 "EHLO mail-lf0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753138AbbKCJl2 (ORCPT ); Tue, 3 Nov 2015 04:41:28 -0500 Received: by lfgh9 with SMTP id h9so10950725lfg.1 for ; Tue, 03 Nov 2015 01:41:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=from:to:cc:subject:date:message-id; bh=GnHMk7MrP2BN2fNHfVsefztaxZ1WRBdYYs8U0YWPAF8=; b=XOCUAlHGYkdyqNhGfHpfTlz7DYLfiZdx0tuZJqmzWHIF1/mwL5jF33+1tYmtyEY3Ng LHWnqN7h1CYQNbGwxjNYoSWkkkH4qJDlr73KTTYpM8HhTtGLxoA3TAr+vYqy6BR4LpbK PFtbw9tSgLeocY+0D+XsMkh3o3zOPru9y2oqI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=GnHMk7MrP2BN2fNHfVsefztaxZ1WRBdYYs8U0YWPAF8=; b=GJ1+o8LmIYC8fwPHXwg8+l9mA27lhfZyDiwSaYB4zozBl5XkCzqvb3NPviS1TFsq1I 67hSgkiuJlVPKyTt9daApaaD2ukCmR88F8VnSPl6k2dGCnkeByEtSXgBpnKxLuZTcfde PHCsGe182cUwy01mTTqV8utwOkYlTwAM9UGwpalyp+NwO0lAGuzYjk+BHgMnDlYThpNK zLr9YacgzKCM4fTW16LQwCvlXV4R0oWRKAuHTs9r96th1yZNJ29XraF5ymzSgZ0NXvuk yr5KP9bMs7qmAYbjJ9qhrhyg9iWC18bpJZdpU3AlRO/w5H6ClF5C1En4oq0+1AQcvLDL /AMw== X-Gm-Message-State: ALoCoQmXecMJadUT6tRkKxvulwYRRxWZGhRl3XRq7WCVkNF/cgIzvLe5JhNlSW0tNYFGnqV2/pif X-Received: by 10.112.130.138 with SMTP id oe10mr7171622lbb.54.1446543686824; Tue, 03 Nov 2015 01:41:26 -0800 (PST) Received: from garcia.imf.au.dk ([130.225.20.51]) by smtp.gmail.com with ESMTPSA id h184sm4698130lfh.4.2015.11.03.01.41.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Nov 2015 01:41:26 -0800 (PST) From: Rasmus Villemoes To: Alexander Viro Cc: Linus Torvalds , Rasmus Villemoes , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [RFC] vfs: don't bother clearing close_on_exec bit for unused fds Date: Tue, 3 Nov 2015 10:41:19 +0100 Message-Id: <1446543679-28849-1-git-send-email-linux@rasmusvillemoes.dk> X-Mailer: git-send-email 2.6.1 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP In fc90888d07b8 (vfs: conditionally clear close-on-exec flag) a conditional was added to __clear_close_on_exec to avoid dirtying a cache line in the common case where the bit is already clear. However, AFAICT, we don't rely on the close_on_exec bit being clear for unused fds, except as an optimization in do_close_on_exec(); if I haven't missed anything, __{set,clear}_close_on_exec is always called when a new fd is allocated. At the expense of also reading through ->open_fds in do_close_on_exec(), we can avoid accessing the close_on_exec bitmap altogether in close(), which I think is a reasonable trade-off. The conditional added in the commit above still makes sense to avoid the dirtying on the allocation paths, but I also think it might make sense in __set_close_on_exec: I suppose any given app handling a non-trivial amount of fds uses O_CLOEXEC for either almost none or almost all of them. Signed-off-by: Rasmus Villemoes --- 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... fs/file.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/file.c b/fs/file.c index c6986dce0334..93cfbcd450c3 100644 --- a/fs/file.c +++ b/fs/file.c @@ -231,7 +231,8 @@ repeat: static inline void __set_close_on_exec(int fd, struct fdtable *fdt) { - __set_bit(fd, fdt->close_on_exec); + if (!test_bit(fd, fdt->close_on_exec)) + __set_bit(fd, fdt->close_on_exec); } static inline void __clear_close_on_exec(int fd, struct fdtable *fdt) @@ -644,7 +645,6 @@ int __close_fd(struct files_struct *files, unsigned fd) if (!file) goto out_unlock; rcu_assign_pointer(fdt->fd[fd], NULL); - __clear_close_on_exec(fd, fdt); __put_unused_fd(files, fd); spin_unlock(&files->file_lock); return filp_close(file, files); @@ -667,7 +667,7 @@ void do_close_on_exec(struct files_struct *files) fdt = files_fdtable(files); if (fd >= fdt->max_fds) break; - set = fdt->close_on_exec[i]; + set = fdt->close_on_exec[i] & fdt->open_fds[i]; if (!set) continue; fdt->close_on_exec[i] = 0;