Hello All,
I have been working to maximise the kernel sleep time on an embedded device by utilising the dynamic tick and deferrable timer features.
During the course of this work I found that although timers were configured as deferrable, only timers for time interval tv1 were actually being deferred. Reviewing the deferrable timer patch [1], it does appear that the code is written to only defer timers for interval tv1. Therefore, I wanted to ask if this is intentional or not?
I have applied the below patch to defer all deferrable timers regardless of interval and so far it is working on the embedded device. I wanted to share this in case this could be something that could be applied to the mainline.
Please excuse any foolish mistakes I may have made here as this is my first post to your mailing list. Any feedback you could offer would be appreciated.
Cheers
Jon
[1] Deferrable timer patch: http://marc.info/?l=linux-kernel&m=117512286417320&w=2
Signed-off-by: Jon Hunter <[email protected]>
---
kernel/timer.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/kernel/timer.c b/kernel/timer.c
index dee3f64..76a3ac6 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -930,6 +930,9 @@ cascade:
index = slot = timer_jiffies & TVN_MASK;
do {
list_for_each_entry(nte, varp->vec + slot, entry) {
+ if (tbase_get_deferrable(nte->base))
+ continue;
+
found = 1;
if (time_before(nte->expires, expires))
expires = nte->expires;
--
1.5.6.3
On Wed, 14 Jan 2009 14:03:09 -0600 "Hunter, Jon" <[email protected]> wrote:
> Hello All,
>
> I have been working to maximise the kernel sleep time on an embedded device by utilising the dynamic tick and deferrable timer features.
>
> During the course of this work I found that although timers were configured as deferrable, only timers for time interval tv1 were actually being deferred. Reviewing the deferrable timer patch [1], it does appear that the code is written to only defer timers for interval tv1. Therefore, I wanted to ask if this is intentional or not?
>
> I have applied the below patch to defer all deferrable timers regardless of interval and so far it is working on the embedded device. I wanted to share this in case this could be something that could be applied to the mainline.
>
> Please excuse any foolish mistakes I may have made here as this is my first post to your mailing list. Any feedback you could offer would be appreciated.
>
> Cheers
> Jon
>
> [1] Deferrable timer patch: http://marc.info/?l=linux-kernel&m=117512286417320&w=2
>
>
> Signed-off-by: Jon Hunter <[email protected]>
> ---
> kernel/timer.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/timer.c b/kernel/timer.c
> index dee3f64..76a3ac6 100644
> --- a/kernel/timer.c
> +++ b/kernel/timer.c
> @@ -930,6 +930,9 @@ cascade:
> index = slot = timer_jiffies & TVN_MASK;
> do {
> list_for_each_entry(nte, varp->vec + slot, entry) {
> + if (tbase_get_deferrable(nte->base))
> + continue;
> +
> found = 1;
> if (time_before(nte->expires, expires))
> expires = nte->expires;
Venki, could you please take a look?
Andrew Morton <mailto:[email protected]> wrote on Thursday, January 15, 2009 12:16 AM:
> Venki, could you please take a look?
Andrew, Venki, if it helps here are some more details.
The function "__next_timer_interrupt()" (in file kernel/timer.c) consists of two main loops. The first loop (shown below) looks for timer events in tv1.
898 /* Look for timer events in tv1. */
899 index = slot = timer_jiffies & TVR_MASK;
900 do {
901 list_for_each_entry(nte, base->tv1.vec + slot, entry) {
902 if (tbase_get_deferrable(nte->base))
903 continue;
904
905 found = 1;
906 expires = nte->expires;
907 /* Look at the cascade bucket(s)? */
908 if (!index || slot < index)
909 goto cascade;
910 return expires;
911 }
912 slot = (slot + 1) & TVR_MASK;
913 } while (slot != index);
You can see from the above code snippet, that if a timer event is found for tv1, then it performs a test to see if this timer event is deferrable (lines 902 and 903). If no timer events are found for tv1, then the code enters a second loop, a for-loop with a nested do-while loop, that looks for timer events in tv2-tv5.
927 for (array = 0; array < 4; array++) {
928 struct tvec *varp = varray[array];
929
930 index = slot = timer_jiffies & TVN_MASK;
931 do {
932 list_for_each_entry(nte, varp->vec + slot, entry) {
933 found = 1;
934 if (time_before(nte->expires, expires))
935 expires = nte->expires;
936 }
937 /*
938 * Do we still search for the first timer or are
939 * we looking up the cascade buckets ?
940 */
941 if (found) {
942 /* Look at the cascade bucket(s)? */
943 if (!index || slot < index)
944 break;
945 return expires;
946 }
947 slot = (slot + 1) & TVN_MASK;
948 } while (slot != index);
949
950 if (index)
951 timer_jiffies += TVN_SIZE - index;
952 timer_jiffies >>= TVN_BITS;
953 }
In the above code, you will see that if a timer event is found there is no test to see if this timer event is deferrable. The patch that I proposed simply adds two lines of code that performs the same test as seen in the tv1 loop to check if a timer is deferrable for tv2-tv5. In other words, add lines 902 and 903, in between lines 932 and 933 in the function __next_timer_interrupt().
Cheers
Jon
>-----Original Message-----
>From: Hunter, Jon [mailto:[email protected]]
>Sent: Monday, January 26, 2009 10:24 AM
>To: Andrew Morton; Pallipadi, Venkatesh
>Cc: [email protected]
>Subject: RE: [RFC] Dynamic Tick and Deferrable Timer Support
>
>Andrew Morton <mailto:[email protected]> wrote on
>Thursday, January 15, 2009 12:16 AM:
>
>> Venki, could you please take a look?
>
>Andrew, Venki, if it helps here are some more details.
>
Jon,
I looked at your patch earlier, but I was concerned about few things and wanted to spend some more time on it. So, I did not reply earlier. The potential issues I see:
- May be a bit theoritcal, as this may not happen in reality. But, with your change, if all the timers happen to be defrrable, timer wheel never advances and none of the timers expire. Not sure whether we need to handle this cleanly somehow or assume that not all the timers will be deferrable.
- Another similar case is when we have more of deferrable timers in the system, if we do not cascade timers from the timer wheel, we may end up spending more time in the higher order timer wheel looking through all the timers, as they are at a higher timer granularity, instead of on the lower order timer wheel which will have timers sorted at a lower granularity.
I am not sure whether any of these issues will be a problem in real world or not. But, I think they are something we should be careful about.
Thanks,
Venki -
Pallipadi, Venkatesh <mailto:[email protected]> wrote on Monday, January 26, 2009 1:48 PM:
> I looked at your patch earlier, but I was concerned about few
> things and wanted to spend some more time on it. So, I did
> not reply earlier.
No problem, I was not sure how clear my original email was :-)
> The potential issues I see:
> - May be a bit theoritcal, as this may not happen in reality.
> But, with your change, if all the timers happen to be
> defrrable, timer wheel never advances and none of the timers
> expire. Not sure whether we need to handle this cleanly
> somehow or assume that not all the timers will be deferrable.
So my understanding is, and please correct me if I am wrong, but as long as there is a timer interrupt then the timer wheel will advanced and all deferred timer functions will get executed. If that is the case then we should always be guaranteed a timer interrupt due to the implementation of the dynamic tick.
The dynamic tick defines a maximum sleep period, max_delta_ns, which is a member of the "clock_event_device" structure. This governs the maximum time you could be asleep/idle for. Currently, the variable, "max_delta_ns", is defined as a 32-bit type (long) and for most architectures, if not all, this is configured by calling function "clockevent_delta2ns()". The maximum value that "max_delta_ns" can be assigned by calling clockevent_delta2ns(), is LONG_MAX (0x7fffffff). In nanoseconds the value 0x7fffffff equates to ~2.15 seconds. Hence, the maximum sleep time is ~2.15 seconds and at a minimum we should have at least 1 timer interrupt every ~2.15 seconds.
Do you think that this would be sufficient?
I am actually thinking about proposing another idea to increase the dynamic range of max_delta_ns to we could sleep for longer than ~2.15 seconds.
> - Another similar case is when we have more of deferrable
> timers in the system, if we do not cascade timers from the
> timer wheel, we may end up spending more time in the higher
> order timer wheel looking through all the timers, as they are
> at a higher timer granularity, instead of on the lower order
> timer wheel which will have timers sorted at a lower granularity.
Good point. I don't like the thought spending a lot of time searching through timers. However, on the other hand you could debate that the current implementation of categorising the timer events is designed to make this efficient as possible. So would this be a bad thing?
Anyway, you do confirm that the deferrable timer patch was implemented only to defer timers in the tv1 group?
> I am not sure whether any of these issues will be a problem
> in real world or not. But, I think they are something we
> should be careful about.
Completely, agree. I have been playing around with this on my setup, but the last thing I would want to do is introduce a bug. Hence, thanks for spending sometime to discuss this.
Cheers
Jon
On Mon, 2009-01-26 at 13:41 -0800, Hunter, Jon wrote:
> Pallipadi, Venkatesh <mailto:[email protected]> wrote on Monday, January 26, 2009 1:48 PM:
>
> > I looked at your patch earlier, but I was concerned about few
> > things and wanted to spend some more time on it. So, I did
> > not reply earlier.
>
> No problem, I was not sure how clear my original email was :-)
>
> > The potential issues I see:
> > - May be a bit theoritcal, as this may not happen in reality.
> > But, with your change, if all the timers happen to be
> > defrrable, timer wheel never advances and none of the timers
> > expire. Not sure whether we need to handle this cleanly
> > somehow or assume that not all the timers will be deferrable.
>
> So my understanding is, and please correct me if I am wrong, but as long as there is a timer interrupt then the timer wheel will advanced and all deferred timer functions will get executed. If that is the case then we should always be guaranteed a timer interrupt due to the implementation of the dynamic tick.
>
> The dynamic tick defines a maximum sleep period, max_delta_ns, which is a member of the "clock_event_device" structure. This governs the maximum time you could be asleep/idle for. Currently, the variable, "max_delta_ns", is defined as a 32-bit type (long) and for most architectures, if not all, this is configured by calling function "clockevent_delta2ns()". The maximum value that "max_delta_ns" can be assigned by calling clockevent_delta2ns(), is LONG_MAX (0x7fffffff). In nanoseconds the value 0x7fffffff equates to ~2.15 seconds. Hence, the maximum sleep time is ~2.15 seconds and at a minimum we should have at least 1 timer interrupt every ~2.15 seconds.
>
> Do you think that this would be sufficient?
Agreed. timer interrupt with its max_delta will avoid the situation I
was thinking above.
> I am actually thinking about proposing another idea to increase the dynamic range of max_delta_ns to we could sleep for longer than ~2.15 seconds.
max_delta would depend on the timer in the platform. With HPET this
should be much larger than 2.15 secs.
> > - Another similar case is when we have more of deferrable
> > timers in the system, if we do not cascade timers from the
> > timer wheel, we may end up spending more time in the higher
> > order timer wheel looking through all the timers, as they are
> > at a higher timer granularity, instead of on the lower order
> > timer wheel which will have timers sorted at a lower granularity.
>
> Good point. I don't like the thought spending a lot of time searching through timers. However, on the other hand you could debate that the current implementation of categorising the timer events is designed to make this efficient as possible. So would this be a bad thing?
>
> Anyway, you do confirm that the deferrable timer patch was implemented only to defer timers in the tv1 group?
>
Yes. The initial deferrable timer was done only for tv1 group on
purpose. To keep things simpler and that would catch most of the "small"
timers and avoid them.
> > I am not sure whether any of these issues will be a problem
> > in real world or not. But, I think they are something we
> > should be careful about.
>
> Completely, agree. I have been playing around with this on my setup, but the last thing I would want to do is introduce a bug. Hence, thanks for spending sometime to discuss this.
Ok. Thinking about it a bit more, I think we can push this patch along.
Thomas/Andrew, can one of you pick up this patch..
Thanks,
Venki
Acked-by: Venkatesh Pallipadi <[email protected]>
Oops. Sending with correct address this time.
>-----Original Message-----
>From: [email protected]
>[mailto:[email protected]] On Behalf Of
>Pallipadi, Venkatesh
>Sent: Tuesday, January 27, 2009 10:36 AM
>To: Hunter, Jon
>Cc: Andrew Morton; [email protected]; Thomas Gleixner
>Subject: RE: [RFC] Dynamic Tick and Deferrable Timer Support
>
>On Mon, 2009-01-26 at 13:41 -0800, Hunter, Jon wrote:
>> Pallipadi, Venkatesh <mailto:[email protected]>
>wrote on Monday, January 26, 2009 1:48 PM:
>>
>> > I looked at your patch earlier, but I was concerned about few
>> > things and wanted to spend some more time on it. So, I did
>> > not reply earlier.
>>
>> No problem, I was not sure how clear my original email was :-)
>>
>> > The potential issues I see:
>> > - May be a bit theoritcal, as this may not happen in reality.
>> > But, with your change, if all the timers happen to be
>> > defrrable, timer wheel never advances and none of the timers
>> > expire. Not sure whether we need to handle this cleanly
>> > somehow or assume that not all the timers will be deferrable.
>>
>> So my understanding is, and please correct me if I am wrong,
>but as long as there is a timer interrupt then the timer wheel
>will advanced and all deferred timer functions will get
>executed. If that is the case then we should always be
>guaranteed a timer interrupt due to the implementation of the
>dynamic tick.
>>
>> The dynamic tick defines a maximum sleep period,
>max_delta_ns, which is a member of the "clock_event_device"
>structure. This governs the maximum time you could be
>asleep/idle for. Currently, the variable, "max_delta_ns", is
>defined as a 32-bit type (long) and for most architectures, if
>not all, this is configured by calling function
>"clockevent_delta2ns()". The maximum value that "max_delta_ns"
>can be assigned by calling clockevent_delta2ns(), is LONG_MAX
>(0x7fffffff). In nanoseconds the value 0x7fffffff equates to
>~2.15 seconds. Hence, the maximum sleep time is ~2.15 seconds
>and at a minimum we should have at least 1 timer interrupt
>every ~2.15 seconds.
>>
>> Do you think that this would be sufficient?
>
>Agreed. timer interrupt with its max_delta will avoid the situation I
>was thinking above.
>
>> I am actually thinking about proposing another idea to
>increase the dynamic range of max_delta_ns to we could sleep
>for longer than ~2.15 seconds.
>
>max_delta would depend on the timer in the platform. With HPET this
>should be much larger than 2.15 secs.
>
>> > - Another similar case is when we have more of deferrable
>> > timers in the system, if we do not cascade timers from the
>> > timer wheel, we may end up spending more time in the higher
>> > order timer wheel looking through all the timers, as they are
>> > at a higher timer granularity, instead of on the lower order
>> > timer wheel which will have timers sorted at a lower granularity.
>>
>> Good point. I don't like the thought spending a lot of time
>searching through timers. However, on the other hand you could
>debate that the current implementation of categorising the
>timer events is designed to make this efficient as possible.
>So would this be a bad thing?
>>
>> Anyway, you do confirm that the deferrable timer patch was
>implemented only to defer timers in the tv1 group?
>>
>
>Yes. The initial deferrable timer was done only for tv1 group on
>purpose. To keep things simpler and that would catch most of
>the "small"
>timers and avoid them.
>
>> > I am not sure whether any of these issues will be a problem
>> > in real world or not. But, I think they are something we
>> > should be careful about.
>>
>> Completely, agree. I have been playing around with this on
>my setup, but the last thing I would want to do is introduce a
>bug. Hence, thanks for spending sometime to discuss this.
>
>Ok. Thinking about it a bit more, I think we can push this
>patch along.
>Thomas/Andrew, can one of you pick up this patch..
>
>Thanks,
>Venki
>
>Acked-by: Venkatesh Pallipadi <[email protected]>
>
>--
>To unsubscribe from this list: send the line "unsubscribe
>linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
Pallipadi, Venkatesh wrote:
> max_delta would depend on the timer in the platform. With HPET this
> should be much larger than 2.15 secs.
So I agree that the HPET hardware in newer devices themselves would
allow longer sleep periods. However, this is not the problem I was raising.
The problem is that the dynamic tick uses a 32-bit variable,
max_delta_ns, to define that max sleep time of a device in nanoseconds.
The maximum value that this variable can be assigned is LONG_MAX or
0x7fffffff nanoseconds (see function clockevent_delta2ns). The value
0x7fffffff nanoseconds equates to ~2.15 seconds. Hence, without
increasing the dynamic range of max_delta_ns (ie. make this a 64-bit
integer) or change the base of this variable from nanoseconds to
milliseconds, I don't see how the device will ever sleep for longer than
~2.15 seconds.
I have spent several weeks trying to suppress kernel timers using the
deferred timers and lengthen the sleep time. I am now able to get the
device to sleep for minutes but I found that max_delta_ns is a limiting
factor. I will be surprised if you can sleep for longer than ~2.15
seconds with the current implementation.
Let me know if this makes sense.
> Ok. Thinking about it a bit more, I think we can push this
> patch along.
> Thomas/Andrew, can one of you pick up this patch..
Great thanks.
Jon
On Thu, Jan 29, 2009 at 8:29 AM, Jon Hunter <[email protected]> wrote:
> Pallipadi, Venkatesh wrote:
> I have spent several weeks trying to suppress kernel timers using the
> deferred timers and lengthen the sleep time. I am now able to get the device
> to sleep for minutes but I found that max_delta_ns is a limiting factor. I
> will be surprised if you can sleep for longer than ~2.15 seconds with the
> current implementation.
As an aside, there are some further hardware limitations in the
timekeeping core that limit the amount of time the hardware can sleep.
For instance, the acpi_pm clocksource wraps every 2.5 seconds or so,
so we have to wake up periodically to sample it to avoid wrapping
issues.
Just to be able to deal with all the different hardware out there, the
timekeeping core expects to wake up twice a second to do this
sampling. It may be possible to push this out if you are using other
clocksources (HPET/TSC), but if sleeps for longer then a second are a
needed feature, we probably will need some infrastructure in the
timekeeping core that can be queried to make sure its safe.
thanks
-john
john stultz wrote:
> As an aside, there are some further hardware limitations in the
> timekeeping core that limit the amount of time the hardware can sleep.
> For instance, the acpi_pm clocksource wraps every 2.5 seconds or so,
> so we have to wake up periodically to sample it to avoid wrapping
> issues.
>
> Just to be able to deal with all the different hardware out there, the
> timekeeping core expects to wake up twice a second to do this
> sampling. It may be possible to push this out if you are using other
> clocksources (HPET/TSC), but if sleeps for longer then a second are a
> needed feature, we probably will need some infrastructure in the
> timekeeping core that can be queried to make sure its safe.
The variable "max_delta_ns" is used by the dynamic tick to govern the
maximum time a given device can sleep. Hence, this variable should be
configured as necessary for the device you are using. Therefore, if your
device has a timer that will wrap every 2.5 seconds, then for this
device the "max_delta_ns" should be configure so that it does not exceed
this time.
So what I was proposing is that for devices that have timers that would
allow you to sleep beyond ~2.15 seconds (current max imposed by the
clockevent_delta2ns function), why not increase the dynamic range (make
this a 64-bit variable) or base (ie. from nanoseconds to milliseconds)
to permit longer sleep times for devices that can support them? This
should not have any negative impact on devices that cannot support such
long sleep times.
So far I have not encountered any issues with doing this. Let me know if
this does or does not address your concerns.
Cheers
Jon
On Fri, 2009-01-30 at 13:04 -0600, Jon Hunter wrote:
> john stultz wrote:
> > As an aside, there are some further hardware limitations in the
> > timekeeping core that limit the amount of time the hardware can sleep.
> > For instance, the acpi_pm clocksource wraps every 2.5 seconds or so,
> > so we have to wake up periodically to sample it to avoid wrapping
> > issues.
> >
> > Just to be able to deal with all the different hardware out there, the
> > timekeeping core expects to wake up twice a second to do this
> > sampling. It may be possible to push this out if you are using other
> > clocksources (HPET/TSC), but if sleeps for longer then a second are a
> > needed feature, we probably will need some infrastructure in the
> > timekeeping core that can be queried to make sure its safe.
>
> The variable "max_delta_ns" is used by the dynamic tick to govern the
> maximum time a given device can sleep. Hence, this variable should be
> configured as necessary for the device you are using. Therefore, if your
> device has a timer that will wrap every 2.5 seconds, then for this
> device the "max_delta_ns" should be configure so that it does not exceed
> this time.
>
> So what I was proposing is that for devices that have timers that would
> allow you to sleep beyond ~2.15 seconds (current max imposed by the
> clockevent_delta2ns function), why not increase the dynamic range (make
> this a 64-bit variable) or base (ie. from nanoseconds to milliseconds)
> to permit longer sleep times for devices that can support them? This
> should not have any negative impact on devices that cannot support such
> long sleep times.
No objection to max_delta_ns being increased, but whatever code manages
it will probably need to query the timekeeping core in some fashion to
make sure the timer hardware max isn't larger then the clocksource
hardware max. I've provided a rough sketch at what the timekeeping code
would probably look like below.
> So far I have not encountered any issues with doing this. Let me know if
> this does or does not address your concerns.
There may be some other issues here, such as NTP over-correction issues
(for instance: ntp trying to correct for a 1us offset over the next
second, but ends up applying it for 10 seconds) if we defer for a really
long time. But at that point, we might as well suspend to ram, like the
OLPC does.
thanks
-john
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 900f1b6..2cf9ebd 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -265,6 +265,21 @@ int timekeeping_valid_for_hres(void)
return ret;
}
+
+u64 timekeeping_max_deferment(void)
+{
+ u64 max_nsecs
+ do {
+ seq = read_seqbegin(&xtime_lock);
+
+ max_nsecs = cyc2ns(clock, clock->mask);
+
+ } while (read_seqretry(&xtime_lock, seq));
+
+ return max_nsecs; /* XXX maybe reduce by some amount to be safe? */
+}
+
+
/**
* read_persistent_clock - Return time in seconds from the persistent clock.
*
> -----Original Message-----
> From: Pallipadi, Venkatesh [mailto:[email protected]]
> Sent: Tuesday, January 27, 2009 12:36 PM
> To: Hunter, Jon
> Cc: Andrew Morton; [email protected]; Thomas Gleixner
> Subject: RE: [RFC] Dynamic Tick and Deferrable Timer Support
>
> On Mon, 2009-01-26 at 13:41 -0800, Hunter, Jon wrote:
> > Pallipadi, Venkatesh <mailto:[email protected]> wrote on
> Monday, January 26, 2009 1:48 PM:
> >
> > > I looked at your patch earlier, but I was concerned about few
> > > things and wanted to spend some more time on it. So, I did
> > > not reply earlier.
> >
> > No problem, I was not sure how clear my original email was :-)
> >
> > > The potential issues I see:
> > > - May be a bit theoritcal, as this may not happen in reality.
> > > But, with your change, if all the timers happen to be
> > > defrrable, timer wheel never advances and none of the timers
> > > expire. Not sure whether we need to handle this cleanly
> > > somehow or assume that not all the timers will be deferrable.
> >
> > So my understanding is, and please correct me if I am wrong, but as long
> as there is a timer interrupt then the timer wheel will advanced and all
> deferred timer functions will get executed. If that is the case then we
> should always be guaranteed a timer interrupt due to the implementation of
> the dynamic tick.
> >
> > The dynamic tick defines a maximum sleep period, max_delta_ns, which is
> a member of the "clock_event_device" structure. This governs the maximum
> time you could be asleep/idle for. Currently, the variable,
> "max_delta_ns", is defined as a 32-bit type (long) and for most
> architectures, if not all, this is configured by calling function
> "clockevent_delta2ns()". The maximum value that "max_delta_ns" can be
Pallipadi, Venkatesh wrote:
> Ok. Thinking about it a bit more, I think we can push this patch along.
> Thomas/Andrew, can one of you pick up this patch..
>
> Thanks,
> Venki
>
> Acked-by: Venkatesh Pallipadi <[email protected]>
>
Hi Andrew, Thomas,
Sorry to respond to this old thread, however, I wanted to see if you had any feedback on this patch. Let me know if you would like me to re-post.
Cheers
Jon
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Wed, 8 Apr 2009 14:20:54 -0500 "Hunter, Jon" <[email protected]> wrote:
>
>
> > -----Original Message-----
> > From: Pallipadi, Venkatesh [mailto:[email protected]]
> > Sent: Tuesday, January 27, 2009 12:36 PM
prehistory!
> Let me know if you would like me to re-post.
That would be best.
Andrew Morton wrote:
>> Let me know if you would like me to re-post.
>
> That would be best.
Thanks. I re-posted the patch under a more meaningful title [1]. I also
asked Venki to ack this one too for consistency.
Cheers
Jon
[1] [PATCH] Allow deferrable timers for intervals tv2-tv5 to be deferred
http://marc.info/?l=linux-kernel&m=123928900703751&w=2