linux-kernel - Re: [RFC][PATCH] Introduce CLOCK_REALTIME

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: <1248215479.3298.124.camel@localhost>
Date:	Tue, 21 Jul 2009 15:31:19 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	lkml <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...x.de>, Ingo Molnar <mingo@...e.hu>,
	Andi Kleen <ak@...e.de>, nikolag@...ibm.com,
	Darren Hart <dvhltc@...ibm.com>
Subject: Re: [RFC][PATCH] Introduce CLOCK_REALTIME_COARSE

On Sat, 2009-07-18 at 15:30 -0700, Arjan van de Ven wrote:
> On Sat, 18 Jul 2009 15:09:38 -0700
> john stultz <johnstul@...ibm.com> wrote:
> 
> > After talking with some application writers who want very fast, but
> > not fine-grained timestamps, I decided to try to implement a new
> > clock_ids to clock_gettime(): CLOCK_REALTIME_COARSE and
> > CLOCK_MONOTONIC_COARSE which returns the time at the last tick. This
> > is very fast as we don't have to access any hardware (which can be
> > very painful if you're using something like the acpi_pm clocksource),
> > and we can even use the vdso clock_gettime() method to avoid the
> > syscall. The only trade off is you only get low-res tick grained time
> > resolution.
> 
> Does this tie us to having a tick? I still have hope that we can get
> rid of the tick even when apps are running .... since with CFS we don't
> really need the tick for the scheduler anymore for example....

So it does require some sort of periodic interval. But the granularity
is probably flexible, although I'm not sure it would be of much use if
the granularity gets to be lower then 100hz. 

While being 100% tickless, even when non-idle would be nice, there will
be some need for timekeeping events to prevent clocksource counters from
wrapping, and to do accurate NTP steering.

Even so, the value we're exporting in this patch is the xtime_cache,
which is updated every tick. This is currently used in file
timestamping, so if we go 100% tickless, we'll have to change the file
timestamping to use the actual CLOCK_REALTIME clock_id, which requires a
possibly slow hardware read and would likely hurt fs performance.

So this patch doesn't so much tie us to having a tick or periodic event
any more the the fs timestamping does.

> > me_lock, seq));
> > +
> > +	set_normalized_timespec(&now, now.tv_sec + mono.tv_sec,
> > +				now.tv_nsec + mono.tv_nsec);
> > +	return now;
> > +}
> > +EXPORT_SYMBOL(get_monotonic_coarse);
> > +
> 
> why does this need to be exported ?

Doesn't. Thanks for noticing!

thanks
-john

--
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/