linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: "'Karstens, Nate'" <Nate.Karstens@garmin.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	"Jeff Layton" <jlayton@kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	"Arnd Bergmann" <arnd@arndb.de>,
	Richard Henderson <rth@twiddle.net>,
	"Ivan Kokshaysky" <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	Helge Deller <deller@gmx.de>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Changli Gao <xiaosuo@gmail.com>
Subject: RE: [PATCH 1/4] fs: Implement close-on-fork
Date: Sun, 3 May 2020 13:52:45 +0000	[thread overview]
Message-ID: <4d00ffe759ec4f87bd7f4e663732838b@AcuMS.aculab.com> (raw)
In-Reply-To: <0e884704c25740df8e652d50431facff@garmin.com>

From: Karstens, Nate
> Sent: 01 May 2020 15:45
> Thanks for the suggestion. I looked into it and noticed that do_close_on_exec() appears to have some
> optimizations as well:
> 
> > set = fdt->close_on_exec[i];
> > if (!set)
> > 	continue;
> 
> If we interleave the close-on-exec and close-on-fork flags then this optimization will have to be
> removed. Do you have a sense of which optimization provides the most benefit?

Thinks....
A moderate proportion of exec() will have at least one fd with 'close on exec' set.
Very few fork() will have any fd with 'close on fork' set.
The 'close on fork' table shouldn't be copied to the forked process.
The 'close on exec' table is deleted by exec().

So...
On fork() take a copy and clear the 'close_on_fork' bitmap.
For every bit set lookup the fd and close if the live bit is set.
Similarly exec() clears and acts on the 'close on exec' map.

You should be able to use the same 'close the fds in this bitmap'
function for both cases.

So I think you need two bitmaps.
But the code needs to differentiate between requests to set bits
(which need to allocate/extend the bitmap) and ones to clear/read
bits (which do not).

You might even consider putting the 'live' flag into the fd structure
and using the bitmap value as a 'hint' - which might be hashed.

After all, it is likely that the 'close on exec' processing
will be faster overall if it just loops through the open fd and
checks each in turn!
I doubt many processes actually exec with more than an handful
of open files.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  parent reply	other threads:[~2020-05-03 13:52 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-20  7:15 Implement close-on-fork Nate Karstens
2020-04-20  7:15 ` [PATCH 1/4] fs: " Nate Karstens
2020-04-20 10:25   ` Eric Dumazet
2020-04-22  3:38     ` Changli Gao
2020-04-22  3:41       ` Changli Gao
2020-04-22  8:35     ` David Laight
2020-05-01 14:45     ` Karstens, Nate
2020-05-01 15:23       ` Matthew Wilcox
2020-05-03 13:52       ` David Laight [this message]
2020-04-22 15:36   ` Karstens, Nate
2020-04-22 15:43     ` Matthew Wilcox
2020-04-22 16:02       ` Karstens, Nate
2020-04-22 16:31         ` Bernd Petrovitsch
2020-04-22 16:55           ` David Laight
2020-04-23 12:34             ` Bernd Petrovitsch
2020-04-20  7:15 ` [PATCH 2/4] fs: Add O_CLOFORK flag for open(2) and dup3(2) Nate Karstens
2020-04-20  7:15 ` [PATCH 3/4] fs: Add F_DUPFD_CLOFORK to fcntl(2) Nate Karstens
2020-04-20  7:15 ` [PATCH 4/4] net: Add SOCK_CLOFORK Nate Karstens
2020-04-22 14:32 ` Implement close-on-fork James Bottomley
2020-04-22 15:01 ` Al Viro
2020-04-22 15:18   ` Matthew Wilcox
2020-04-22 15:34     ` James Bottomley
2020-04-22 16:00     ` Al Viro
2020-04-22 16:13       ` Al Viro
2020-05-04 13:46       ` Karstens, Nate

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4d00ffe759ec4f87bd7f4e663732838b@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=Nate.Karstens@garmin.com \
    --cc=arnd@arndb.de \
    --cc=bfields@fieldses.org \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --cc=eric.dumazet@gmail.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jlayton@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=mattst88@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=rth@twiddle.net \
    --cc=sparclinux@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xiaosuo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).