linux-kernel - Re: [PATCH 4/5] select: make select() use schedule

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080829093017.7ff4389d@infradead.org>
Date:	Fri, 29 Aug 2008 09:30:17 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, tglx@...x.de
Subject: Re: [PATCH 4/5] select: make select() use schedule_hrtimeout()

On Fri, 29 Aug 2008 09:20:18 -0700 (PDT)
Linus Torvalds <torvalds@...ux-foundation.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/