Hi,
seems like my first try with the complete patch hasn't made it through
to the mailing list. This is the second try with only the common part of
the patch. Here we go (again):
---
I have a suggestion that might seem unusual at first but it is important
for Linux on S/390. We are facing the
[EMAIL PROTECTED] said:
> I have a suggestion that might seem unusual at first but it is
> important for Linux on S/390. We are facing the problem that we want
> to start many (> 1000) Linux images on a big S/390 machine. Every
> image has its own 100 HZ timer on every processor the images uses
>
this is one of linux biggest weaknesses. the fixed interval timer is a
throwback. it should be replaced with a variable interval timer with interrupts
on demand for any system with a cpu sane/modern enough to have an on-chip
interrupting decrementer. (i.e just about any modern chip)
On Mon, 09
> this is one of linux biggest weaknesses. the fixed interval timer is a
> throwback. it should be replaced with a variable interval timer with interrupts
> on demand for any system with a cpu sane/modern enough to have an on-chip
> interrupting decrementer. (i.e just about any modern chip)
It
On Mon, 09 Apr 2001, Alan Cox wrote:
> > this is one of linux biggest weaknesses. the fixed interval timer is a
> > throwback. it should be replaced with a variable interval timer with interrupts
> > on demand for any system with a cpu sane/modern enough to have an on-chip
> > interrupting decre
> > this is one of linux biggest weaknesses. the fixed interval timer is a
> > throwback. it should be replaced with a variable interval timer with interrupts
> > on demand for any system with a cpu sane/modern enough to have an on-chip
> > interrupting decrementer. (i.e just about any modern c
> > Its worth doing even on the ancient x86 boards with the PIT.
>
> Note that programming the PIT is slw and doing it on every timer
> add_timer/del_timer would be a pain.
You only have to do it occasionally.
When you add a timer newer than the current one
(arguably newer by a
On Mon, Apr 09, 2001 at 02:19:28PM -0400, Mark Salisbury wrote:
> this is one of linux biggest weaknesses. the fixed interval timer is a
> throwback. it should be replaced with a variable interval timer with interrupts
> on demand for any system with a cpu sane/modern enough to have an on-chip
>
>Just how would you do kernel/user CPU time accounting then ? It's
currently done
>on every timer tick, and doing it less often would make it useless.
This part is architecture dependent. For S/390 I choose to do a "STCK" on
every
system entry/exit. Dunno if this can be done on other architectu
>Its worth doing even on the ancient x86 boards with the PIT. It does
require
>some driver changes since
>
>
>while(time_before(jiffies, we_explode))
> poll_things();
>
>no longer works
On S/390 we have a big advantage here. Driver code of this kind does not
exist.
That makes it a lo
Hi!
> Just how would you do kernel/user CPU time accounting then ? It's currently done
> on every timer tick, and doing it less often would make it useless.
Except for machines with very slow timers we really should account time
to processes during context switch instead of sampling on timer t
Martin Mares writes:
> [lost]
>> Just how would you do kernel/user CPU time accounting then ?
>> It's currently done on every timer tick, and doing it less
>> often would make it useless.
>
> Except for machines with very slow timers we really should account time
> to processes during context swi
> > interrupting decrementer. (i.e just about any modern chip)
>
> Just how would you do kernel/user CPU time accounting then ? It's currently done
> on every timer tick, and doing it less often would make it useless.
On the contrary doing it less often but at the right time massively improve
>> Just how would you do kernel/user CPU time accounting then ? It's
currently done
>> on every timer tick, and doing it less often would make it useless.
>
>On the contrary doing it less often but at the right time massively
improves
>its accuracy. You do it on reschedule. An rdtsc instruction
On Mon, Apr 09, 2001 at 11:35:44PM +0100, Alan Cox wrote:
> > > Its worth doing even on the ancient x86 boards with the PIT.
> >
> > Note that programming the PIT is slw and doing it on every timer
> > add_timer/del_timer would be a pain.
>
> You only have to do it occasionally.
>
> Whe
> If you do the accounting on reschedule, how do you find out how much ti=
> me
> has been spent in user versus kernel mode? Or do the Intel chips have t=
> wo
> counters, one for user space execution and one for the kernel?
Unfortunately not so you'd need to do a little bit per syscall, at least
On Tue, Apr 10, 2001 at 12:18:03PM +0100, Alan Cox wrote:
> > > interrupting decrementer. (i.e just about any modern chip)
> >
> > Just how would you do kernel/user CPU time accounting then ? It's currently done
> > on every timer tick, and doing it less often would make it useless.
>
> On th
> > > > Its worth doing even on the ancient x86 boards with the PIT.
> > >
> > > Note that programming the PIT is slw and doing it on every timer
> > > add_timer/del_timer would be a pain.
> >
> > You only have to do it occasionally.
> >
> > When you add a timer newer than the current o
> Does not sound very attractive all at all on non virtual machines (I see the point on
> UML/VM):
> making system entry/context switch/interrupts slower, making add_timer slower, just
>to
> process a few less timer interrupts. That's like robbing the fast paths for a slow
>path.
Measure the n
which kind of U/K accaounting are you referring to?
are you referring to global changes in world time? are you referring to time
used by a process?
I think the reduction of clock interrupts by a factor of 10 would buy us some
performance margin that could be traded for a slightly more complex h
On Mon, 09 Apr 2001, Alan Cox wrote:
>
> Its worth doing even on the ancient x86 boards with the PIT. It does require
> some driver changes since
>
>
> while(time_before(jiffies, we_explode))
> poll_things();
>
> no longer works
jiffies could be replaced easily enough w/ a
On Tue, 10 Apr 2001, Martin Mares wrote:
> Except for machines with very slow timers we really should account time
> to processes during context switch instead of sampling on timer ticks.
> The current values are in many situations (i.e., lots of processes
> or a process frequently waiting for eve
On Tue, Apr 10, 2001 at 01:12:14PM +0100, Alan Cox wrote:
> Measure the number of clocks executing a timer interrupt. rdtsc is fast. Now
> consider the fact that out of this you get KHz or better scheduling
> resolution required for games and midi. I'd say it looks good. I agree
And measure the
On Tue, Apr 10, 2001 at 02:04:17PM +0200, Mikulas Patocka wrote:
>
> Adding and removing timers happens much more frequently than PIT tick, so
> comparing these times is pointless.
>
> If you have some device and timer protecting it from lockup on buggy
> hardware, you actually
>
> send request
On Tue, 10 Apr 2001, David Schleef wrote:
> i.e., the TSC, you have to use 8254 timer 0 as both the timebase
> and the interval counter -- you end up slowly losing time because
> of the race condition between reading the timer and writing a
> new interval.
actually, I have an algorithm to fix t
> It's also all interrupts, not only syscalls, and also context switch if you
> want to be accurate.
We dont need to be that accurate. Our sample rate is currently so low the
data is worthless anyway
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
On Tue, 10 Apr 2001, Alan Cox wrote:
> > Does not sound very attractive all at all on non virtual machines (I see the point
>on
> > UML/VM):
> > making system entry/context switch/interrupts slower, making add_timer slower,
>just to
> > process a few less timer interrupts. That's like robbing t
On Tue, Apr 10, 2001 at 01:36:27PM +0100, Alan Cox wrote:
> > It's also all interrupts, not only syscalls, and also context switch if you
> > want to be accurate.
>
> We dont need to be that accurate. Our sample rate is currently so low the
> data is worthless anyway
Just without checking on con
On Tue, Apr 10, 2001 at 08:07:04AM -0400, Mark Salisbury wrote:
> which kind of U/K accaounting are you referring to?
>
> are you referring to global changes in world time? are you referring to time
> used by a process?
The later.
>
> I think the reduction of clock interrupts by a factor of 1
On Tue, 10 Apr 2001, David Schleef wrote:
> This just indicates that the interface needs to be richer -- i.e.,
> such as having a "lazy timer" that means: "wake me up when _at least_
> N ns have elapsed, but there's no hurry." If waking you up at N ns
> is expensive, then the wakeup is delayed un
On Tue, 10 Apr 2001, Andi Kleen wrote:
> Also generally the kernel has quite a lot of timers.
are these generaly of the long interval, failure timeout type?
i.e. 5 second device timeouts that are killed before they get executed because
the device didn't timeout? if so, they have no effect
>Does not sound very attractive all at all on non virtual machines (I see
the point on
>UML/VM):
>making system entry/context switch/interrupts slower, making add_timer
slower, just to
>process a few less timer interrupts. That's like robbing the fast paths
for a slow path.
The system entry/exit
On Tue, Apr 10, 2001 at 08:42:33AM -0400, Mark Salisbury wrote:
> On Tue, 10 Apr 2001, Andi Kleen wrote:
> > Also generally the kernel has quite a lot of timers.
>
> are these generaly of the long interval, failure timeout type?
A lot of them are, but not all.
-Andi
-
To unsubscribe from
> > Note that you call mod_timer also on each packet received - and in worst
> > case (which may happen), you end up reprogramming the PIT on each packet.
>
> This just indicates that the interface needs to be richer -- i.e.,
> such as having a "lazy timer" that means: "wake me up when _at least_
On Tue, Apr 10, 2001 at 04:10:28PM +0200, Mikulas Patocka wrote:
> Timers more precise than 100HZ aren't probably needed - as MIN_RTO is 0.2s
> and MIN_DELACK is 0.04s, TCP would hardly benefit from them.
On networking bandwidth shaping and traffic control generally need higher precision
timers.
Mikulas Patocka wrote:
> BTW. Why we need to redesign timers at all? The cost of timer interrupt
> each 1/100 second is nearly zero (1000 instances on S/390 VM is not common
> case - it is not reasonable to degradate performance of timers because of
> this).
>
> Timers more precise than 100HZ are
>BTW. Why we need to redesign timers at all? The cost of timer interrupt
>each 1/100 second is nearly zero (1000 instances on S/390 VM is not common
>case - it is not reasonable to degradate performance of timers because of
>this).
The cost of the timer interrupts on a single image system is neg
> Timers more precise than 100HZ aren't probably needed - as MIN_RTO is 0.2s
> and MIN_DELACK is 0.04s, TCP would hardly benefit from them.
There are a considerable number of people who really do need 1Khz resolution.
Midi is one of the example cases. That doesn't mean we have to go to a 1KHz
tim
Mikulas Patocka wrote:
> Timers more precise than 100HZ aren't probably needed - as MIN_RTO is 0.2s
> and MIN_DELACK is 0.04s, TCP would hardly benefit from them.
Indeed, using precise timers for TCP would probably degrade performance
-- you should process a group of timer events together, when r
> Games would like to be able to page flip at vertical refresh time --
> <1ms accuracy please. Network traffic shaping benefits from better than
This is an X issue. I was talking with Jim Gettys about what is needed to
get the relevant existing X extensions for this working
-
To unsubscribe fro
Alan Cox wrote:
> > Games would like to be able to page flip at vertical refresh time --
> > <1ms accuracy please. Network traffic shaping benefits from better than
>
> This is an X issue. I was talking with Jim Gettys about what is needed to
> get the relevant existing X extensions for this wor
> > This is an X issue. I was talking with Jim Gettys about what is needed to
> > get the relevant existing X extensions for this working
>
> Last time I looked at XF86DGA (years ago), it seemed to have the right
> hooks in place. Just a matter of server implementation. My
> recollection is dus
Alan Cox wrote:
> > > This is an X issue. I was talking with Jim Gettys about what is needed to
> > > get the relevant existing X extensions for this working
> >
> > Last time I looked at XF86DGA (years ago), it seemed to have the right
> > hooks in place. Just a matter of server implementation.
Just for your information we have a project going that is trying to come
up with a good solution for all of this:
http://sourceforge.net/projects/high-res-timers
We have a mailing list there where we have discussed much of the same
stuff. The mailing list archives are available at sourceforge.
Alan Cox wrote:
>
> > Games would like to be able to page flip at vertical refresh time --
> > <1ms accuracy please. Network traffic shaping benefits from better than
>
> This is an X issue. I was talking with Jim Gettys about what is needed to
> get the relevant existing X extensions for this
When this is rewritten, I would strongly suggest that we find a way to
make 'gettimeofday' nearly free. Certain applications need to use this
frequently while still being portable. One solution when you do have
clock ticks is a read-only mapped Int. Another cheap solution is
library assembly th
Jamie Lokier wrote:
>
> Alan Cox wrote:
>
> Except for cards which don't generate an irq on vsync but do let you see
> how the raster is proceeding. (I vaguely recall these). For which a
> PLL and, wait for it high resolution timer is needed.
>
> Perhaps that's a 1990s problem that doesn
george anzinger wrote:
> f) As noted, the account timers (task user/system times) would be much
> more accurate with the tick less approach. The cost is added code in
> both the system call and the schedule path.
>
> Tentative conclusions:
>
> Currently we feel that the tick less approach is not
On Tue, Apr 10, 2001 at 02:45:15PM -0400, Stephen D. Williams wrote:
> When this is rewritten, I would strongly suggest that we find a way to
> make 'gettimeofday' nearly free. Certain applications need to use this
> frequently while still being portable. One solution when you do have
> clock ti
mark salisbury wrote:
>
> george anzinger wrote:
>
> > f) As noted, the account timers (task user/system times) would be much
> > more accurate with the tick less approach. The cost is added code in
> > both the system call and the schedule path.
> >
> > Tentative conclusions:
> >
> > Currently
> mark salisbury wrote:
> >
> > george anzinger wrote:
> >
> > > f) As noted, the account timers (task user/system times) would be much
> > > more accurate with the tick less approach. The cost is added code in
> > > both the system call and the schedule path.
> > >
> > > Tentative conclusions:
Mark Salisbury wrote:
>
> > mark salisbury wrote:
> > >
> > > george anzinger wrote:
> > >
> > > > f) As noted, the account timers (task user/system times) would be much
> > > > more accurate with the tick less approach. The cost is added code in
> > > > both the system call and the schedule pat
Mark Salisbury wrote:
>
> It would probably be a good compile config option to allow fine or coarse
> process time accounting, that leaves the choice to the person setting up the
> system to make the choice based on their needs.
>
I suggested this a while ago during a discussion about performan
>f) As noted, the account timers (task user/system times) would be much
>more accurate with the tick less approach. The cost is added code in
>both the system call and the schedule path.
>
>Tentative conclusions:
>
>Currently we feel that the tick less approach is not acceptable due to
>(f). W
On Tue, 10 Apr 2001, Zdenek Kabelac wrote:
> I think it would be wrong if we could not add new very usable features
> to the system just because some old hardware doesn't support it.
s/old/crappy/ -- even old hardware can handle vsync IRQs fine. E.g. TVGA
8900C.
--
+ Maciej W. Rozycki, Tec
On Tue, Apr 10, 2001 at 04:43:36AM -0700, David Schleef wrote:
> However, on machines without a monotonically increasing counter,
> i.e., the TSC, you have to use 8254 timer 0 as both the timebase
> and the interval counter -- you end up slowly losing time because
> of the race condition between r
Mark Salisbury wrote:
> > The complexity comes in when you want to maintain indexes into the list
> > for quick insertion of new timers. To get the current insert
> > performance, for example, you would need pointers to (at least) each of
> > the next 256 centasecond boundaries in the list. But
Maciej W. Rozycki wrote:
> On Tue, 10 Apr 2001, Zdenek Kabelac wrote:
>
> > I think it would be wrong if we could not add new very usable features
> > to the system just because some old hardware doesn't support it.
>
> s/old/crappy/ -- even old hardware can handle vsync IRQs fine. E.g. TVGA
>
Jamie Locker wrote:
>
> Mark Salisbury wrote:
> > > The complexity comes in when you want to maintain indexes into the list
> > > for quick insertion of new timers. To get the current insert
> > > performance, for example, you would need pointers to (at least) each of
> > > the next 256 centasec
On Mon, 9 Apr 2001, Alan Cox wrote:
> > > Its worth doing even on the ancient x86 boards with the PIT.
> >
> > Note that programming the PIT is slw and doing it on every timer
> > add_timer/del_timer would be a pain.
>
> You only have to do it occasionally.
>
> When you add a timer newer
george anzinger wrote:
> > A pointer-based priority queue is really not a very complex thing, and
> > there are ways to optimise them for typical cases like the above.
> >
> Please do enlighten me. The big problem in my mind is that the
> pointers, pointing at points in time, are perishable.
Um
On Wed, 11 Apr 2001 20:57:04 +0200, Jamie Lokier
<[EMAIL PROTECTED]> wrote:
>george anzinger wrote:
>> > A pointer-based priority queue is really not a very complex thing, and
>> > there are ways to optimise them for typical cases like the above.
>> >
>> Please do enlighten me. The big problem
Mikulas Patocka ([EMAIL PROTECTED]) wrote:
> Adding and removing timers happens much more frequently than PIT tick,
> so
> comparing these times is pointless.
>
> If you have some device and timer protecting it from lockup on buggy
> hardware, you actually
>
> send request to device
> add tim
> I suspect you might go for ticked if its overhead was less. The thing
> that makes me think the overhead is high for tick less is the accounting
> and time slice stuff. This has to be handled each system call and each
> schedule call. These happen WAY more often than ticks... Contrary
> wise
Alan Cox wrote:
>
> > Timers more precise than 100HZ aren't probably needed - as MIN_RTO is 0.2s
> > and MIN_DELACK is 0.04s, TCP would hardly benefit from them.
>
> There are a considerable number of people who really do need 1Khz resolution.
> Midi is one of the example cases. That doesn't mea
John Alvord wrote:
> I bumped into a funny non-optimization a few years ago. A system with
> a timer queue like the above had been "optimized" by keeping old timer
> elements... ready for new tasks to link onto and activate. The
> granularity was 1 millsecond. Over time, all timer values from 0 to
watermodem wrote:
> As somebody who is now debating how to measure latencies in a
> giga-bit ethernet environment with several components doing
> L3 switching in much less than 10 micro-seconds ... (hardware)
> I agree that some method is need to achieve higher resolutions.
> (Sigh... I will l
On Wed, 11 Apr 2001, Jamie Lokier wrote:
> Think of the original 64k and 256k VGA cards. I think some of those
> didn't have an irq, but did have a way to read the progress of the
> raster, which you could PLL to using timer interrupts. Some video games
> still look fine at 320x200 :-)
The *o
On Wed, 11 Apr 2001, Bret Indrelee wrote:
> Current generation PCs can easily handle 1000s of
> interrupts a second if you keep the overhead small.
the PC centric implementation of the ticked system is one of its major flaws.
there are architectures which the cost of a fixed interval is the sam
On Thu, 12 Apr 2001, Mark Salisbury wrote:
> On Wed, 11 Apr 2001, Bret Indrelee wrote:
> > Current generation PCs can easily handle 1000s of
> > interrupts a second if you keep the overhead small.
>
> the PC centric implementation of the ticked system is one of its major flaws.
>
> there are arc
Bret Indrelee wrote:
>
> Mikulas Patocka ([EMAIL PROTECTED]) wrote:
> > Adding and removing timers happens much more frequently than PIT tick,
> > so
> > comparing these times is pointless.
> >
> > If you have some device and timer protecting it from lockup on buggy
> > hardware, you actually
> >
On Thu, 12 Apr 2001, george anzinger wrote:
> Bret Indrelee wrote:
> > Keep all timers in a sorted double-linked list. Do the insert
> > intelligently, adding it from the back or front of the list depending on
> > where it is in relation to existing entries.
>
> I think this is too slow, especial
Bret Indrelee wrote:
>
> On Thu, 12 Apr 2001, george anzinger wrote:
> > Bret Indrelee wrote:
> > > Keep all timers in a sorted double-linked list. Do the insert
> > > intelligently, adding it from the back or front of the list depending on
> > > where it is in relation to existing entries.
> >
>
On Thu, 12 Apr 2001, george anzinger wrote:
> Bret Indrelee wrote:
> >
> > On Thu, 12 Apr 2001, george anzinger wrote:
> > > Bret Indrelee wrote:
> > > > Keep all timers in a sorted double-linked list. Do the insert
> > > > intelligently, adding it from the back or front of the list depending on
Bret Indrelee wrote:
>
> On Thu, 12 Apr 2001, george anzinger wrote:
> > Bret Indrelee wrote:
> > >
> > > On Thu, 12 Apr 2001, george anzinger wrote:
> > > > Bret Indrelee wrote:
> > > > > Keep all timers in a sorted double-linked list. Do the insert
> > > > > intelligently, adding it from the ba
Ben Greear wrote:
>
> Bret Indrelee wrote:
> >
> > On Thu, 12 Apr 2001, george anzinger wrote:
> > > Bret Indrelee wrote:
> > > >
> > > > On Thu, 12 Apr 2001, george anzinger wrote:
> > > > > Bret Indrelee wrote:
> > > > > > Keep all timers in a sorted double-linked list. Do the insert
> > > > >
george anzinger wrote:
> > Wouldn't a heap be a good data structure for a list of timers? Insertion
> > is log(n) and finding the one with the least time is O(1), ie pop off the
> > front It can be implemented in an array which should help cache
> > coherency and all those other things they
Jamie Lokier wrote:
>
> george anzinger wrote:
> > > Wouldn't a heap be a good data structure for a list of timers? Insertion
> > > is log(n) and finding the one with the least time is O(1), ie pop off the
> > > front It can be implemented in an array which should help cache
> > > coherency
Ben Greear <[EMAIL PROTECTED]> said:
[...]
> Wouldn't a heap be a good data structure for a list of timers? Insertion
> is log(n) and finding the one with the least time is O(1), ie pop off the
> front It can be implemented in an array which should help cache
> coherency and all those othe
Horst von Brand wrote:
>
> Ben Greear <[EMAIL PROTECTED]> said:
>
> [...]
>
> > Wouldn't a heap be a good data structure for a list of timers? Insertion
> > is log(n) and finding the one with the least time is O(1), ie pop off the
> > front It can be implemented in an array which should h
george anzinger wrote:
> If we are to do high-res-timers, I think we will always have to do some
> sort of a sort on insert.
Yes, that's called a priority queue... (And you don't actually sort on
each insertion).
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
george anzinger wrote:
> Horst von Brand wrote:
> >
> > Ben Greear <[EMAIL PROTECTED]> said:
> >
> > [...]
> >
> > > Wouldn't a heap be a good data structure for a list of timers? Insertion
> > > is log(n) and finding the one with the least time is O(1), ie pop off the
> > > front It can
george anzinger wrote:
>
> Horst von Brand wrote:
> >
> > Ben Greear <[EMAIL PROTECTED]> said:
> >
> > [...]
> >
> > > Wouldn't a heap be a good data structure for a list of timers? Insertion
> > > is log(n) and finding the one with the least time is O(1), ie pop off the
> > > front It can
Jamie Lokier wrote:
>
> george anzinger wrote:
> > Horst von Brand wrote:
> > >
> > > Ben Greear <[EMAIL PROTECTED]> said:
> > >
> > > [...]
> > >
> > > > Wouldn't a heap be a good data structure for a list of timers? Insertion
> > > > is log(n) and finding the one with the least time is O(1), i
Ben Greear wrote:
> > Note that jumping around the array thrashes no more cache than
> > traversing a tree (it touches the same number of elements). I prefer
> > heap-ordered trees though because fixed size is always a bad idea.
>
> With a tree, you will be allocating and de-allocating for every
all this talk about which data structure to use and how to allocate memory is
wy premature.
there needs to be a clear definition of the requirements that we wish to meet,
including whether we are going to do ticked, tickless, or both
a func spec, for lack of a better term needs to be develop
Mark Salisbury wrote:
>
> all this talk about which data structure to use and how to allocate memory is
> wy premature.
>
> there needs to be a clear definition of the requirements that we wish to meet,
> including whether we are going to do ticked, tickless, or both
>
> a func spec, for la
> CLOCK_10MS a wall clock supporting timers with 10 ms resolution (same as
> linux today).
Except on the Alpha, and on some ARM systems, etc.
The HZ constant varies from 10 to 1200.
> At the same time we will NOT support the following clocks:
>
> CLOCK_VIRTUAL a clock measuring the elapsed exe
"Albert D. Cahalan" wrote:
>
> > CLOCK_10MS a wall clock supporting timers with 10 ms resolution (same as
> > linux today).
>
> Except on the Alpha, and on some ARM systems, etc.
> The HZ constant varies from 10 to 1200.
I suspect we will want to use 10 ms resolution for a clock named
CLOCK_10M
> Given a system speed, there is a repeating timer rate which will consume
> 100% of the system in handling the timer interrupts. An attempt will
> be made to detect this rate and adjust the timer to prevent system
> lockup. This adjustment will look like timer overruns to the user
> (i.e. we w
Mark Salisbury wrote:
>
> > Given a system speed, there is a repeating timer rate which will consume
> > 100% of the system in handling the timer interrupts. An attempt will
> > be made to detect this rate and adjust the timer to prevent system
> > lockup. This adjustment will look like timer o
On Mon, 16 Apr 2001, you wrote:
> Mark Salisbury wrote:
> >
> > > Given a system speed, there is a repeating timer rate which will consume
> > > 100% of the system in handling the timer interrupts. An attempt will
> > > be made to detect this rate and adjust the timer to prevent system
> > > loc
> Functional Specification for the high-res-timers project.
>
> In addition we expect that we will provide a high resolution timer for
> kernel use (heck, we may provide several).
what we do here determines what we can do for the user..
> We will provide several "clocks" as defined by the stan
Mark Salisbury wrote:
>
> > Functional Specification for the high-res-timers project.
> >
> > In addition we expect that we will provide a high resolution timer for
> > kernel use (heck, we may provide several).
>
> what we do here determines what we can do for the user..
I was thinking that it
george anzinger wrote:
> > > a.) list insertion of an arbitrary timer,
> > should be O(log(n)) at worst
> >
> > > b.) removal of canceled and expired timers, and
> > easy to make O(1)
>
> I thought this was true also, but the priority heap structure that has
> been discussed here has a O(log(n))
IMHO the POSIX is doable to comply with POSIX. Probably not what many
of the RT freaks expect, but doable. I'm tuning the nanoseconds for a
while now...
Ulrich
On 17 Apr 2001, at 11:53, george anzinger wrote:
> I was thinking that it might be good to remove the POSIX API for the
> kernel and
On Mon, 23 Apr 2001, Ulrich Windl wrote:
> IMHO the POSIX is doable to comply with POSIX. Probably not what many
> of the RT freaks expect, but doable. I'm tuning the nanoseconds for a
> while now...
>
> Ulrich
thanks for calling me a freak :)
yes, linux could have posix timers cobbled on tod
Okay but what will be used for a base for hardware that has critical
timing issues due to the rules of the hardware?
I do not care but your drives/floppy/tapes/cdroms/cdrws do:
/*
* Timeouts for various operations:
*/
#define WAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms
> Okay but what will be used for a base for hardware that has critical
> timing issues due to the rules of the hardware?
> #define WAIT_MIN_SLEEP (2*HZ/100) /* 20msec - minimum sleep time */
>
> Give me something for HZ or a rule for getting a known base so I can have
> your storage work a
On Fri, 13 Apr 2001, Alan Cox wrote:
> > Okay but what will be used for a base for hardware that has critical
> > timing issues due to the rules of the hardware?
>
> > #define WAIT_MIN_SLEEP (2*HZ/100) /* 20msec - minimum sleep time */
> >
> > Give me something for HZ or a rule for gettin
1 - 100 of 113 matches
Mail list logo
