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 for Android: free password hash cracker in your pocket

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

Message-ID: <20080829104220.600096a5@infradead.org>
Date:	Fri, 29 Aug 2008 10:42:20 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, 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 10:26:02 -0700 (PDT)
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> 
> 
> On Fri, 29 Aug 2008, Alan Cox wrote:
> >
> > > "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).
> > 
> > I disagree - that is fixing the problem in the wrong place. The
> > timer structure needs an accuracy field of some form that the
> > existing timer functions initialise to 0.
> 
> I do agree that we could do that too, but you miss one big issue:
> even if we were to add an accuracy field inside the kernel, there is
> no such field in the user interfaces.
> 
> We just pass timevals (and sometimes timespecs) around, and no, they
> don't have any way to specify accuracy.
> 
> Yeah, we could use the high bits in the usec/nsec words, but then
> older kernels would basically do random things, so that would be a
> horrible interface.
> 
> The other thing to do would be to just add totally new system calls
> with totally new interfaces, but (a) nobody would use them anyway and
> (b) it's simply not worth it.
> 
> So given that reality, and _if_ we want to support nice
> high-resolution sleeping by select/poll, the only reasonable thing to
> do is to estimate some kind of expected accuracy from the existing
> timeval/timespec.
> 
> And the only reasonable way to do that is to just look at the range.
> You can probably do something fairly trivial with


that works

one of the things we were thinking about was to also have a field in
the task struct (so inherited over fork/exec) that is the default
"slack", which can be set via a prctl, so that an admin can do a "nice"
like thing and run certain known silly apps at different granularity
(and a bunch of smart tricks in some key apps that we'll then do)



-- 
If you want to reach me at my work email, use arjan@...ux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/