From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S270433AbTGMXCD (ORCPT ); Sun, 13 Jul 2003 19:02:03 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S270434AbTGMXCD (ORCPT ); Sun, 13 Jul 2003 19:02:03 -0400 Received: from x35.xmailserver.org ([208.129.208.51]:59783 "EHLO x35.xmailserver.org") by vger.kernel.org with ESMTP id S270433AbTGMXCC (ORCPT ); Sun, 13 Jul 2003 19:02:02 -0400 X-AuthUser: davidel@xmailserver.org Date: Sun, 13 Jul 2003 16:09:23 -0700 (PDT) From: Davide Libenzi X-X-Sender: davide@bigblue.dev.mcafeelabs.com To: David Schwartz cc: Jamie Lokier , Eric Varsanyi , Linux Kernel Mailing List Subject: RE: [Patch][RFC] epoll and half closed TCP connections In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 13 Jul 2003, David Schwartz wrote: > It's not O(N) with 'poll' and 'select'. Twice as many file descriptors > means twice as many active file descriptors which means twice as many > discovered per call to 'poll'. If the calls to 'poll' are further apart It is O(N), if N if the number of fds queried. The poll code does "at least" 2 * N loops among the set (plus other stuff), and hence it is O(N). Even if you do N "nop" in your implementation, this becomes O(N) from a mathematical point of view. - Davide