From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755872AbbKDMdc (ORCPT <rfc822;w@1wt.eu>);
	Wed, 4 Nov 2015 07:33:32 -0500
Received: from mail-pa0-f48.google.com ([209.85.220.48]:36563 "EHLO
	mail-pa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750703AbbKDMdb (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 4 Nov 2015 07:33:31 -0500
Message-ID: <1446640408.4184.18.camel@edumazet-glaptop2.roam.corp.google.com>
Subject: Re: [RFC] vfs: don't bother clearing close_on_exec bit for unused
 fds
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Date: Wed, 04 Nov 2015 04:33:28 -0800
In-Reply-To: <87egg6c9nw.fsf@rasmusvillemoes.dk>
References: <1446543679-28849-1-git-send-email-linux@rasmusvillemoes.dk>
	 <1446600672.4184.1.camel@edumazet-glaptop2.roam.corp.google.com>
	 <87egg6c9nw.fsf@rasmusvillemoes.dk>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 2015-11-04 at 11:59 +0100, Rasmus Villemoes wrote:

> @@ -667,10 +665,9 @@ 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;


Many processes have a big hole at the end of fdt->open_fds[], due
to the fact that max_fds is rounded to a power of two.

It makes sense to avoid bringing in cpu caches the close_on_exec[] part.


set = fdt->open_fds[i];
if (!set)
	continue;
set &= fdt->close_on_exec[i];
if (!set)
	continue;

Not sure if this is a net win due to branch prediction...