Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754509AbYKBWt4 (ORCPT ); Sun, 2 Nov 2008 17:49:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753600AbYKBWts (ORCPT ); Sun, 2 Nov 2008 17:49:48 -0500 Received: from x35.xmailserver.org ([64.71.152.41]:55623 "EHLO x35.xmailserver.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753447AbYKBWtr (ORCPT ); Sun, 2 Nov 2008 17:49:47 -0500 X-AuthUser: davidel@xmailserver.org Date: Sun, 2 Nov 2008 14:49:41 -0800 (PST) From: Davide Libenzi X-X-Sender: davide@alien.or.mcafeemobile.com To: Olaf van der Spek cc: Linux Kernel Mailing List Subject: Re: epoll behaviour after running out of descriptors In-Reply-To: Message-ID: References: X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640 56FE 0974 BF23 270F 474E X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1682 Lines: 40 On Sun, 2 Nov 2008, Olaf van der Spek wrote: > On Sun, Nov 2, 2008 at 10:17 PM, Davide Libenzi wrote: > >> Wouldn't the port space require about 20+ k connects? This issue > >> happens after 1 k. > > > > The reason for "When accept returns EMFILE, I call epoll_wait and accept > > and it returns with another EMFILE." is because your sockets-close logic > > is broken. > > It's not broken, it's designed that way. It's designed to hit the > descriptor limit and then close all sockets some time after. > > > You get an event for the listening fd, you go call accept(2) > > and in one or two passes you fill up the avail fd space, then you go back > > calling epoll_wait(), and yet back to accept(2). This w/out triggering the > > file-close-relief code (yes, you fill up 1K fds *before* 30 seconds). Of > > course you get another EMFILE. > > The second EMFILE doesn't make sense, epoll_wait shouldn't signal the > socket as ready again, right? At the time of the first EMFILE, you've filled up the fd space, but not the kernel listen backlog. Additions to the backlog, triggers new events, that you see after the first EMFILE. At a given point, the backlog is full, so no new half connections are dropped in there, so no new events are generated. Again, sleeping on (EMFILE && ET) is bad mojo, and nowhere is written that events should be generated in the EMFILE->no-EMFILE transitions. - Davide -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/