[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090718153011.1de3af8e@infradead.org>
Date: Sat, 18 Jul 2009 15:30:11 -0700
From: Arjan van de Ven <arjan@...radead.org>
To: john stultz <johnstul@...ibm.com>
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, 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....
> 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 ?
--
Arjan van de Ven Intel Open Source Technology Centre
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/
Powered by blists - more mailing lists