Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758039AbYH2Qan (ORCPT ); Fri, 29 Aug 2008 12:30:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757146AbYH2QaW (ORCPT ); Fri, 29 Aug 2008 12:30:22 -0400 Received: from casper.infradead.org ([85.118.1.10]:52369 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756923AbYH2QaU (ORCPT ); Fri, 29 Aug 2008 12:30:20 -0400 Date: Fri, 29 Aug 2008 09:30:17 -0700 From: Arjan van de Ven To: Linus Torvalds Cc: linux-kernel@vger.kernel.org, mingo@elte.hu, tglx@tglx.de Subject: Re: [PATCH 4/5] select: make select() use schedule_hrtimeout() Message-ID: <20080829093017.7ff4389d@infradead.org> In-Reply-To: References: <20080829080549.6906b744@infradead.org> <20080829080809.0e42a323@infradead.org> Organization: Intel X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2051 Lines: 54 On Fri, 29 Aug 2008 09:20:18 -0700 (PDT) Linus Torvalds wrote: > > > On Fri, 29 Aug 2008, Arjan van de Ven wrote: > > > > now that we have schedule_hrtimeout(), make select() use it. > > But only for short delays; really long delays are assumed to not > > need the highres level of accuracy but rather want the regular > > timer behavior for now. > > This is _really_ ugly. > > Can't you just do this relaxation in "schedule_hrtimeout()" instead, > and just document the fact that the "high resolution" of hrtimeout is > relative to the length of the timeout. yes we can (sorry, bad pun) > It's not that select() doesn't care, it's that *NOBODY* cares. If > somebody asks for a timeout of one second and 2 microseconds, the two > microseconds simply don't matter. Ever. But if somebody asks for a > timeout of 12 microseconds, individual microseconds probably _do_ > matter. ok I'll do it this way; I wanted to avoid changing behavior for long delays (some people think there's too much overhead in hrtimers or something) but i'm totally fine with not doing this bifurbicated braintwist at all. > > So if you want high-resolution select/poll, then get rid of the > "use_hr" logic entirely, and just do it unconditionally. Then, relax > the scheduler timeouts in the scheduler. ok, no big deal, see below > > (But, that's probably _generally_ true. Even now, when people do > "schedule_timeout()", there's a big difference between asking for two > ticks and asking for two seconds. The latter should probably try to > round to a nice timer tick basis for power reasons). yes that's a separate story; this is what "range timers" are about and David Woodhouse and I are working on that as well (but this select stuff is basically a prerequisite to use that) -- 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/