linux-kernel - Re: itimer again (Re: [PATCH] RTC: Add mmap method to rtc character driver)

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]

Date:	Sun, 30 Jul 2006 02:16:59 +0200
From:	Edgar Toernig <froese@....de>
To:	Bill Huey (hui) <billh@...ppy.monkey.org>
Cc:	Neil Horman <nhorman@...driver.com>, Jim Gettys <jg@...top.org>,
	"H. Peter Anvin" <hpa@...or.com>, Dave Airlie <airlied@...il.com>,
	Segher Boessenkool <segher@...nel.crashing.org>,
	linux-kernel@...r.kernel.org, a.zummo@...ertech.it,
	jg@...edesktop.org, Keith Packard <keithp@...thp.com>,
	Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	"Bill Huey (hui)" <billh@...ppy.monkey.org>
Subject: Re: itimer again (Re: [PATCH] RTC: Add mmap method to rtc character
 driver)

Bill Huey (hui) wrote:
>
> > You mean something like this, /dev/itimer?
> > 
> >     http://marc.theaimsgroup.com/?m=115412412427996
> 
> [CCing Steve and Ingo on this thread]
> 
> It's a different topic than what Keith needs,

Hmm, actually, people with problems like Keith's are the target
audience, or at least were meant to be.  See the mmap example
I posted in the original thread.

> but this is useful for another set of purposes. It's something that's
> really useful in the RT patch since there isn't a decent API to get at
> high resolution timers in userspace.

The /dev/itimer wasn't meant for high resolution, only accurate and
reliable within the limits of the jiffy counter and easy to use. That
doesn't mean that it can't be improved to provide high resolution; only,
that this wasn't the design goal.  But I think, that the API is good
enough to provide high resolution at any time without changing user
space code.

(IMHO most people consider a resolution of 1 ms to be "high enough".)

> If itimer can be abstracted a bit so it serves more generically as a bidirection
> communication pipe, not just to a timer (although it's good for now), but
> possibly to bandwidth scheduler policies as a backend, then you have the
> possibility of this driver being a real winner. The blocking read can be a
> yield to get information on soft overruns for that allocation cycle and the
> write can be an intelligent yield for when scheduling wheel wraps around to
> soft skip a cycle or something. It'll depend on the semantics of the scheduling
> policy.

Hm... I'm not sure what you mean.  Sure, a blocking read may be a nice hint
to the scheduler because we know exactly how long we're gonna sleep.  But
I think that a blocking read is used very seldom.  Normally, the apps would
block via select/poll.  And then the hints become looser - you only know
the latest time when the process definitely wants to run again.

Another scheduling hint could be the set interval.  One could assume that
an app that sets an interval of 1/50th second does want to run regularly
every 1/50th second.  But that may be hard to use for scheduling decisions,
especially when an app starts to use more than one timer.

Ciao, ET.
-
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/