From owner-freebsd-hackers  Sun Jun 17 14:56: 8 2001
Delivered-To: freebsd-hackers@freebsd.org
Received: from superconductor.rush.net (superconductor.rush.net [208.9.155.8])
	by hub.freebsd.org (Postfix) with ESMTP id 676A737B401
	for <freebsd-hackers@FreeBSD.ORG>; Sun, 17 Jun 2001 14:55:54 -0700 (PDT)
	(envelope-from bright@superconductor.rush.net)
Received: (from bright@localhost)
	by superconductor.rush.net (8.11.2/8.11.2) id f5HLtfK05479;
	Sun, 17 Jun 2001 17:55:41 -0400 (EDT)
Date: Sun, 17 Jun 2001 17:55:38 -0400
From: Alfred Perlstein <bright@rush.net>
To: Sascha Schumann <sascha@schumann.cx>
Cc: Valentin Nechayev <netch@iv.nn.kiev.ua>,
	freebsd-hackers@FreeBSD.ORG
Subject: Re: poll(2)'s arbitrary limit
Message-ID: <20010617175537.P1832@superconductor.rush.net>
References: <20010617155740.O1832@superconductor.rush.net> <Pine.LNX.4.33.0106172157290.6072-200000@rossini.schumann.cx>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <Pine.LNX.4.33.0106172157290.6072-200000@rossini.schumann.cx>; from sascha@schumann.cx on Sun, Jun 17, 2001 at 10:28:54PM +0200
X-all-your-base: are belong to us.
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-hackers.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-hackers>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-hackers>
X-Loop: FreeBSD.ORG

* Sascha Schumann <sascha@schumann.cx> [010617 16:29] wrote:
> > >     I've been using kern.maxproc=kern.maxprocfiles=2*32768 for my
> > >     tests and that worked successfully.
> >
> > Ok, so then we don't need to change FreeBSD?
> 
>     Well, it would be cool, if an administrator could impose a
>     more restrictive limit on the maximum number of open fds
>     while still allowing applications to poll large sets of fds.
> 
>     For example, the appended patch adds kern.maxfilesperpoll
>     which is used in place of the current check in poll().  This
>     could be used to fine-tune servers for specific
>     configurations more easily.  At the same time, it would get
>     rid of the (per the sys_generic.c comment) "bogus" relation
>     between fd limits and the limits imposed by poll(2).

The problem with this is that it wouldn't have solved your problem,
you would have still recieved EINVAL (most likely) although you
could then raise 'maxfilesperpoll'.  What I was proposing was a
less strict limit, perhaps your delta however we should set
maxfilesperpoll to MAXFILES * 2, or...

change:
     if (nfds > p->p_rlimit[RLIMIT_NOFILE].rlim_cur && nfds > FD_SETSIZE)
to:
     if (nfds > 2 * p->p_rlimit[RLIMIT_NOFILE].rlim_cur && nfds > 2 * FD_SETSIZE)

either one would be ok by me.

So you see a problem with setting it to MAXFILES * 2?

-Alfred


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message