High-res-timers part 2 (x86 platform code) take 5.1

This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms.

Quoted 4 lines · george anzinger

This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms.

I really don't get the notion of partial ticks, and quite frankly, this isn't going into my tree until some major distribution kicks me in the head and explains to me why the hell we have partial ticks instead of just making the ticks shorter.

Quoted 12 lines · Linus Torvalds

Quoted 4 lines · george anzinger

This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms.

I really don't get the notion of partial ticks, and quite frankly, this isn't going into my tree until some major distribution kicks me in the head and explains to me why the hell we have partial ticks instead of just making the ticks shorter.

Well, the notion is to provide timers that have resolution down into the micro seconds. Since this take a bit more overhead, we just set up an interrupt on an as needed basis. This is why we define both a high res and a low res clock. Timers on the low res clock will always use the 1/HZ tick to drive them and thus do not introduce any additional overhead. If this is all that is needed the configure option can be left off and only these timers will be available.

On the other hand, if a user requires better resolution, s/he just turns on the high-res option and incures the overhead only when it is used and then only at timer expire time. Note that the only way to access a high-res timer is via the POSIX clocks and timers API. They are not available to select or any other system call.

Making ticks shorter causes extra overhead ALL the time, even when it is not needed. Higher resolution is not free in any case, but it is much closer to free with this patch than by increasing HZ (which, of course, can still be done). Overhead wise and resolution wise, for timers, we would be better off with a 1/HZ tick and the "on demand" high-res interrupts this patch introduces.

Quoted 30 lines · george anzinger

Quoted 12 lines · Linus Torvalds

Quoted 4 lines · george anzinger

This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms.

I really don't get the notion of partial ticks, and quite frankly, this isn't going into my tree until some major distribution kicks me in the head and explains to me why the hell we have partial ticks instead of just making the ticks shorter.

Well, the notion is to provide timers that have resolution down into the micro seconds. Since this take a bit more overhead, we just set up an interrupt on an as needed basis. This is why we define both a high res and a low res clock. Timers on the low res clock will always use the 1/HZ tick to drive them and thus do not introduce any additional overhead. If this is all that is needed the configure option can be left off and only these timers will be available.

On the other hand, if a user requires better resolution, s/he just turns on the high-res option and incures the overhead only when it is used and then only at timer expire time. Note that the only way to access a high-res timer is via the POSIX clocks and timers API. They are not available to select or any other system call.

Quoted 7 lines

Making ticks shorter causes extra overhead ALL the time, even when it is not needed. Higher resolution is not free in any case, but it is much closer to free with this patch than by increasing HZ (which, of course, can still be done). Overhead wise and resolution wise, for timers, we would be better off with a 1/HZ tick and the "on demand" high-res interrupts this patch introduces.

??? The issue of ticks is separate from the issue of how often timer interrupts fire. Ticks just becomes the maximum resolution you can support/express.

If it makes sense to have two maximum tick resolutions. The normal application maximum tick rate and the special task maximum tick rate it is probably worth making this only available as a capability or an rlimit.

Quoted 12 lines · Linus Torvalds

Quoted 4 lines · george anzinger

This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms.

I really don't get the notion of partial ticks, and quite frankly, this isn't going into my tree until some major distribution kicks me in the head and explains to me why the hell we have partial ticks instead of just making the ticks shorter.

Well, the notion is to provide timers that have resolution down into the micro seconds. Since this take a bit more overhead, we just set up an interrupt on an as needed basis. This is why we define both a high res and a low res clock. Timers on the low res clock will always use the 1/HZ tick to drive them and thus do not introduce any additional overhead. If this is all that is needed the configure option can be left off and only these timers will be available.

On the other hand, if a user requires better resolution, s/he just turns on the high-res option and incures the overhead only when it is used and then only at timer expire time. Note that the only way to access a high-res timer is via the POSIX clocks and timers API. They are not available to select or any other system call.

Making ticks shorter causes extra overhead ALL the time, even when it is not needed. Higher resolution is not free in any case, but it is much closer to free with this patch than by increasing HZ (which, of course, can still be done). Overhead wise and resolution wise, for timers, we would be better off with a 1/HZ tick and the "on demand" high-res interrupts this patch introduces.

Quoted 30 lines · george anzinger

Quoted 12 lines · Linus Torvalds

Quoted 4 lines · george anzinger

This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms.

I really don't get the notion of partial ticks, and quite frankly, this isn't going into my tree until some major distribution kicks me in the head and explains to me why the hell we have partial ticks instead of just making the ticks shorter.

Well, the notion is to provide timers that have resolution down into the micro seconds. Since this take a bit more overhead, we just set up an interrupt on an as needed basis. This is why we define both a high res and a low res clock. Timers on the low res clock will always use the 1/HZ tick to drive them and thus do not introduce any additional overhead. If this is all that is needed the configure option can be left off and only these timers will be available.

On the other hand, if a user requires better resolution, s/he just turns on the high-res option and incures the overhead only when it is used and then only at timer expire time. Note that the only way to access a high-res timer is via the POSIX clocks and timers API. They are not available to select or any other system call.

Quoted 7 lines

Making ticks shorter causes extra overhead ALL the time, even when it is not needed. Higher resolution is not free in any case, but it is much closer to free with this patch than by increasing HZ (which, of course, can still be done). Overhead wise and resolution wise, for timers, we would be better off with a 1/HZ tick and the "on demand" high-res interrupts this patch introduces.

I think what Linus is getting at is: why not make the units of jiffies microseconds and give it larger increments on clock ticks? Now you don't need any special logic to go to better than HZ resolution. Unfortunately, this means identifying all the things that use HZ as a measure of how often we check for rescheduling.

There's also an issue of dynamic range - if we some day soon decide we want internal timestamps with nanosecond resolution (because units of .1us are annoying, not because we'll actually have ns accuracy), then we're seeing timer wraps every couple seconds on 32bit machines and we're pretty much forced to break into seconds and nanoseconds. This is arguably saner than jiffies and subjiffies, but it forces people who are using long timeouts today to use a new interface.

I don't think he can seriously mean cranking HZ up to match whatever timing requirements we might have - that obviously doesn't scale.

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
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/

Quoted 40 lines · Oliver Xymoron

Quoted 37 lines · george anzinger

Quoted 12 lines · Linus Torvalds

Quoted 4 lines · george anzinger

This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms.

I really don't get the notion of partial ticks, and quite frankly, this isn't going into my tree until some major distribution kicks me in the head and explains to me why the hell we have partial ticks instead of just making the ticks shorter.

Well, the notion is to provide timers that have resolution down into the micro seconds. Since this take a bit more overhead, we just set up an interrupt on an as needed basis. This is why we define both a high res and a low res clock. Timers on the low res clock will always use the 1/HZ tick to drive them and thus do not introduce any additional overhead. If this is all that is needed the configure option can be left off and only these timers will be available.

On the other hand, if a user requires better resolution, s/he just turns on the high-res option and incures the overhead only when it is used and then only at timer expire time. Note that the only way to access a high-res timer is via the POSIX clocks and timers API. They are not available to select or any other system call.

Making ticks shorter causes extra overhead ALL the time, even when it is not needed. Higher resolution is not free in any case, but it is much closer to free with this patch than by increasing HZ (which, of course, can still be done). Overhead wise and resolution wise, for timers, we would be better off with a 1/HZ tick and the "on demand" high-res interrupts this patch introduces.

Quoted 5 lines

I think what Linus is getting at is: why not make the units of jiffies microseconds and give it larger increments on clock ticks? Now you don't need any special logic to go to better than HZ resolution. Unfortunately, this means identifying all the things that use HZ as a measure of how often we check for rescheduling.

Well then you are still dealing with two measures, the HZ and the tick rate.

One might also argue that the subjiffie
should be some "normal" thing like nanosecond or micro second. I went round and round with this in the beginning. What it comes down to it the conversion back and forth is much easier and faster (less overhead) when using the natural units of the underlying clock. This way the interrupt code, for example, does not have to even do a conversion.

Quoted 2 lines

I don't think he can seriously mean cranking HZ up to match whatever timing requirements we might have - that obviously doesn't scale.

This is at least the third "take" on what he means, each of which sends me in a very different direction. Sure would like to know what he really means.

Quoted 41 lines · george anzinger

Quoted 40 lines · Oliver Xymoron

Quoted 37 lines · george anzinger

Quoted 12 lines · Linus Torvalds

Quoted 4 lines · george anzinger

This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms.

I really don't get the notion of partial ticks, and quite frankly, this isn't going into my tree until some major distribution kicks me in the head and explains to me why the hell we have partial ticks instead of just making the ticks shorter.

Well, the notion is to provide timers that have resolution down into the micro seconds. Since this take a bit more overhead, we just set up an interrupt on an as needed basis. This is why we define both a high res and a low res clock. Timers on the low res clock will always use the 1/HZ tick to drive them and thus do not introduce any additional overhead. If this is all that is needed the configure option can be left off and only these timers will be available.

On the other hand, if a user requires better resolution, s/he just turns on the high-res option and incures the overhead only when it is used and then only at timer expire time. Note that the only way to access a high-res timer is via the POSIX clocks and timers API. They are not available to select or any other system call.

Making ticks shorter causes extra overhead ALL the time, even when it is not needed. Higher resolution is not free in any case, but it is much closer to free with this patch than by increasing HZ (which, of course, can still be done). Overhead wise and resolution wise, for timers, we would be better off with a 1/HZ tick and the "on demand" high-res interrupts this patch introduces.

Quoted 8 lines

Quoted 5 lines

I think what Linus is getting at is: why not make the units of jiffies microseconds and give it larger increments on clock ticks? Now you don't need any special logic to go to better than HZ resolution. Unfortunately, this means identifying all the things that use HZ as a measure of how often we check for rescheduling.

Well then you are still dealing with two measures, the HZ and the tick rate.

Yep, and separating the two breaks a few things. Granted.

Quoted 8 lines

One might also argue that the subjiffie
should be some "normal" thing like nanosecond or micro second. I went round and round with this in the beginning. What it comes down to it the conversion back and forth is much easier and faster (less overhead) when using the natural units of the underlying clock. This way the interrupt code, for example, does not have to even do a conversion.

Then the argument becomes move jiffies to the most convenient unit that encompasses what you want to do with subjiffies. Microseconds was just an example. Most code doesn't really care when ticks happen, except to the extent that they currently trigger timers, so jiffies=tick HZ stops being a meaningful measure once timers are untied from ticks, see?

Quoted 7 lines

Quoted 3 lines

I don't think he can seriously mean cranking HZ up to match whatever timing requirements we might have - that obviously doesn't scale.

This is at least the third "take" on what he means, each of which sends me in a very different direction. Sure would like to know what he really means.

Perhaps if you pose it as a multiple-choice question? I suppose he's almost sure to answer with "none of the above".

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
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/

Quoted 3 lines · george anzinger

This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms.

I really don't get the notion of partial ticks, and quite frankly, this isn't going into my tree until some major distribution kicks me in the head and explains to me why the hell we have partial ticks instead of just making the ticks shorter.

Linus

Quoted 7 lines · Linus Torvalds

Quoted 3 lines · george anzinger

This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms.

Quoted 4 lines

I really don't get the notion of partial ticks, and quite frankly, this isn't going into my tree until some major distribution kicks me in the head and explains to me why the hell we have partial ticks instead of just making the ticks shorter.

Quoted 1 line

Linus

In any kind of virtual environment you would rather prefer a completely tickless system alltogether than increased tick rates. In a S/390 virtual machine, running many hundreds of virtual Linux servers the 100Hz timer pops are already considerably painful, and going to a higher tick rate achieving higher timer resolution is completely prohibitive. Similar is true in many embedded systems related to power consumption of high frequency ticks.

However, George has shown that introducing the notion of a completely tickless system is expensive on Intel overhead wise, thus partial ticks seem to be a possibility addressing the needs for embedded and virtual environments, getting decent timer resolution as needed.

Quoted 9 lines

Quoted 9 lines

Quoted 3 lines

This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms.

I really don't get the notion of partial ticks, and quite frankly, this isn't going into my tree until some major distribution kicks me in the head and explains to me why the hell we have partial ticks instead of just making the ticks shorter.

Not speaking for a major distro, just for me writing HPET (high performance event timer ...) support for x86-64 (and it happens to exist on ia64 as well, and possibly might be in new Intel P4 chipsets, too).

It's a very nice piece of hardware that allows very fine granularity aperiodic interrupts (in each interrupt you set when the next one will happen), without much overhead.

Hi!

Quoted 10 lines

Quoted 9 lines

Quoted 9 lines

Quoted 3 lines

This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms.

I really don't get the notion of partial ticks, and quite frankly, this isn't going into my tree until some major distribution kicks me in the head and explains to me why the hell we have partial ticks instead of just making the ticks shorter.

Quoted 7 lines

Not speaking for a major distro, just for me writing HPET (high performance event timer ...) support for x86-64 (and it happens to exist on ia64 as well, and possibly might be in new Intel P4 chipsets, too).

It's a very nice piece of hardware that allows very fine granularity aperiodic interrupts (in each interrupt you set when the next one will happen), without much overhead.

I believe the problem is like this: assume you have three timers, 10msec polling of mouse, 30msec keyboard autorepeat and 50msec cursor blinking. With current approach, you get

10msec userland runs
<enter kernel>
<process mouse>
<process keyboard>
<process cursor>
<exit kernel>

With hires timers, you get:

3msec userland runs
<enter kernel>
<process mouse>
<exit kernel>
2msec userland runs
<enter kernel>
<process keyboard>
<exit kernel>
...

which is not so efficient. I guess rounding could be implemented to preserve this "do-all-together" ability?

Quoted 43 lines · Pavel Machek

Hi!

Quoted 10 lines

Quoted 9 lines

Quoted 9 lines

Quoted 3 lines

This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms.

I really don't get the notion of partial ticks, and quite frankly, this isn't going into my tree until some major distribution kicks me in the head and explains to me why the hell we have partial ticks instead of just making the ticks shorter.

Quoted 7 lines

Not speaking for a major distro, just for me writing HPET (high performance event timer ...) support for x86-64 (and it happens to exist on ia64 as well, and possibly might be in new Intel P4 chipsets, too).

It's a very nice piece of hardware that allows very fine granularity aperiodic interrupts (in each interrupt you set when the next one will happen), without much overhead.

I believe the problem is like this: assume you have three timers, 10msec polling of mouse, 30msec keyboard autorepeat and 50msec cursor blinking. With current approach, you get

10msec userland runs
<enter kernel>
<process mouse>
<process keyboard>
<process cursor>
<exit kernel>

With hires timers, you get:

3msec userland runs
<enter kernel>
<process mouse>
<exit kernel>
2msec userland runs
<enter kernel>
<process keyboard>
<exit kernel>
...

Quoted 2 lines

which is not so efficient. I guess rounding could be implemented to preserve this "do-all-together" ability?

Actually that's exactly why you'd want sub-tick timing. For timers where you don't care too much about the timing ;) you could do the rounding, and for those where you need exact timing (sound, video, ...) you could call a different add_timer() which would disable the coalescing.

Carrier Grade Linux is not a distro, but we do integrate these patches into the CGL patches and will continue to use it.

Please consider adding it to 2.5.

On Wed, 9 Oct 2002, Linus Torvalds wrote:

| On Wed, 9 Oct 2002, george anzinger wrote:
| > This patch, in conjunction with the "core" high-res-timers
| > patch implements high resolution timers on the i386
| > platforms.
|
| I really don't get the notion of partial ticks, and quite frankly, this
| isn't going into my tree until some major distribution kicks me in the
| head and explains to me why the hell we have partial ticks instead of
| just making the ticks shorter.
| -