Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932200AbVIXRW7 (ORCPT ); Sat, 24 Sep 2005 13:22:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932201AbVIXRW7 (ORCPT ); Sat, 24 Sep 2005 13:22:59 -0400 Received: from willy.net1.nerim.net ([62.212.114.60]:17158 "EHLO willy.net1.nerim.net") by vger.kernel.org with ESMTP id S932200AbVIXRW6 (ORCPT ); Sat, 24 Sep 2005 13:22:58 -0400 Date: Sat, 24 Sep 2005 19:20:11 +0200 From: Willy Tarreau To: Davide Libenzi Cc: Willy Tarreau , Nish Aravamudan , Linux Kernel Mailing List , Andrew Morton Subject: Re: [patch] sys_epoll_wait() timeout saga ... Message-ID: <20050924172011.GA25997@alpha.home.local> References: <20050924040534.GB18716@alpha.home.local> <29495f1d05092321447417503@mail.gmail.com> <20050924061500.GA24628@alpha.home.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.10i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1615 Lines: 35 On Sat, Sep 24, 2005 at 08:10:32AM -0700, Davide Libenzi wrote: > >+ jtimeout = timeout < 0 || \ > >+ timeout >= (1000ULL * MAX_SCHEDULE_TIMEOUT / HZ) || > >\ > >+ timeout >= (LONG_MAX / HZ - 1000) ? > > MAX_SCHEDULE_TIMEOUT: (timeout * HZ + 999) / 1000; > > > >as both are constants, they can be optimized. Otherwise, we can resort to > >using a MAX() macro to reduce this to only one test which will catch all > >corner cases. > > Using the MIN() macro would be better so we have a single check, and the > compiler optimize that automatically. you're right, it's MIN() not MAX() ;-) Anyway, I've checked the code and the compiler does a single test with -O2. > Or we can force 'timeout * HZ' to use ULL math. I don't think it makes a lot of difference for something that is in a likely sleep path ;) "likely", yes, but not necessarily. Under a high load, you can have enough events queued so that epoll() will not wait at all. I've already encountered such cases during benchmarks, and I noticed that epoll() took more time than select() for small numbers of FDs (something like 20% below 100 FDs), but of course, it is considerably faster above. So turning the multiply to an ULL may increase this overhead on some architectures, while the double check will leave the code identical. Regards, Willy - 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/