Peter Zijlstra wrote:
On Fri, 2008-08-01 at 09:25 -0400, Josef Bacik wrote:
Index: linux-2.6/fs/jbd/transaction.c
===================================================================
--- linux-2.6.orig/fs/jbd/transaction.c
+++ linux-2.6/fs/jbd/transaction.c
@@ -63,6 +65,32 @@ get_transaction(journal_t *journal, tran
return transaction;
}
+static void precision_sleep(unsigned long time)
+{
+ struct hrtimer_sleeper t;
+
+ hrtimer_init_on_stack(&t.timer, CLOCK_REALTIME, HRTIMER_MODE_ABS);
+ hrtimer_init_sleeper(&t, current);
+ t.timer.expires = ktime_add_ns(ktime_get_real(), time);
+
+ do {
+ set_current_state(TASK_UNINTERRUPTIBLE);
+
+ hrtimer_start(&t.timer, t.timer.expires, HRTIMER_MODE_ABS);
+ if (!hrtimer_active(&t.timer))
+ t.task = NULL;
+
+ if (likely(t.task))
+ schedule();
+
+ hrtimer_cancel(&t.timer);
+ } while (t.task);
+
+ set_current_state(TASK_RUNNING);
+
+ destroy_hrtimer_on_stack(&t.timer);
+}
+
/*
* Handle management.
*
I was convinced we already had such a creature,. but I guess I was wrong
as I can't find it ;-)
Anyway, I'm thinking this function ought to live in kernel/hrtimer.c and
possibly get renamed to something like hrtimer_sleep_ns() or some such
(means you can also reuse the do_nanosleep helper in there).
Also, have you considered the impact on platforms that do not support
hrtimers, or don't have high resolution clock events available?
I agree that this is definitely a much more generically interesting
function.
With high res timers, falling back to the jiffie's granularity (or not
sleeping at all in the case of the file system transaction batching)
seems to be a reasonable fall back,
ric
Index: linux-2.6/kernel/hrtimer.c
===================================================================
--- linux-2.6.orig/kernel/hrtimer.c
+++ linux-2.6/kernel/hrtimer.c
@@ -1458,6 +1458,7 @@ void hrtimer_init_sleeper(struct hrtimer
sl->timer.cb_mode = HRTIMER_CB_IRQSAFE_NO_SOFTIRQ;
#endif
}
+EXPORT_SYMBOL_GPL(hrtimer_init_sleeper);
static int __sched do_nanosleep(struct hrtimer_sleeper *t, enum hrtimer_mode mode)
{
That also gets rid of this export..
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
