From owner-cvs-src@FreeBSD.ORG  Mon Mar 17 18:40:35 2008
Return-Path: <owner-cvs-src@FreeBSD.ORG>
Delivered-To: cvs-src@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 2180D1065670;
	Mon, 17 Mar 2008 18:40:35 +0000 (UTC)
	(envelope-from sobomax@FreeBSD.org)
Received: from sippysoft.com (gk1.360sip.com [72.236.70.240])
	by mx1.freebsd.org (Postfix) with ESMTP id BE9328FC27;
	Mon, 17 Mar 2008 18:40:34 +0000 (UTC)
	(envelope-from sobomax@FreeBSD.org)
Received: from [192.168.0.36] ([204.244.149.125]) (authenticated bits=0)
	by sippysoft.com (8.13.8/8.13.8) with ESMTP id m2HIeO46042301
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Mar 2008 11:40:25 -0700 (PDT)
	(envelope-from sobomax@FreeBSD.org)
Message-ID: <47DEBB0D.8090304@FreeBSD.org>
Date: Mon, 17 Mar 2008 11:40:13 -0700
From: Maxim Sobolev <sobomax@FreeBSD.org>
Organization: Sippy Software, Inc.
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Jeff Roberson <jroberson@chesapeake.net>
References: <200803160621.m2G6LUlE034766@repoman.freebsd.org>
	<20080316100836.F44049@fledge.watson.org>
	<47DDED1F.8000707@FreeBSD.org> <20080317020036.M910@desktop>
In-Reply-To: <20080317020036.M910@desktop>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org,
	Robert Watson <rwatson@FreeBSD.org>, cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/sys/sys eventhandler.h src/sys/kern
 kern_descrip.c uipc_socket.c
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Mar 2008 18:40:35 -0000

Jeff Roberson wrote:
> On Sun, 16 Mar 2008, Maxim Sobolev wrote:
> 
>> Robert Watson wrote:
>>> On Sun, 16 Mar 2008, Maxim Sobolev wrote:
>>>
>>>> sobomax     2008-03-16 06:21:30 UTC
>>>>
>>>>  FreeBSD src repository
>>>>
>>>>  Modified files:
>>>>    sys/sys              eventhandler.h
>>>>    sys/kern             kern_descrip.c uipc_socket.c
>>>>  Log:
>>>>  Properly set size of the file_zone to match kern.maxfiles parameter.
>>>>  Otherwise the parameter is no-op, since zone by default limits number
>>>>  of descriptors to some 12K entries. Attempt to allocate more ends up
>>>>  sleeping on zonelimit.
>>>
>>> Hmm.  Could you be more specific about the nature of the problem 
>>> you're seeing here?  UMA shouldn't impose any default zone limit on 
>>> the file_zone if none is set.  Are you sure it's the struct file 
>>> zonelimit you're running into, and not, say, the socket zone limit, etc?
>>
>> Yes, you are right, further investigation revealed that in my case I 
>> was hitting maxsockets limit, not maxfiles limit. Not sure if the 
>> backout is in order or having files zone limit has some value, so that 
>> possible leaks can be detected and UMA zone can potentially do 
>> size-based optimizations in the future?
> 
> The UMA max is complicated due to per-cpu caches.  Really the limit code 
> in uma should be rewritten or all consumers should handle it themselves 
> the way struct file does.  It'd probably be best if you backed this out.

OK, no problem, but I have two question:

1. What to do with SI_SUB_EVENTHANDLER+1 in the socket code and 
SI_SUB_LOCK in the old file descriptor code? Neither looks good.

2. Also I wonder why hitting sockets limit works differently than file 
descriptors limit. In the latter case the program gets the proper error 
code (ENFILE) instantly, while in the former the program just hangs 
sleeping on the UMA zone limit. Perhaps socket(2) should fail in such 
case with either ENFILE or ENOBUFS?

-Maxim