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
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
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))
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
> 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
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
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
> 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
"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
Hi!
> /*
> * Timeouts for various operations:
> */
> #define WAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms */
> #ifdef CONFIG_APM
> #define WAIT_READY (5*HZ) /* 5sec - some laptops are very slow */
Broken broken broken. CONFIG_APM has *nothing* to do with mac
> 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
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
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
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
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
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
Roger Larsson wrote:
>
> On Thursday 12 April 2001 23:52, Andre Hedrick wrote:
> > 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:
> >
> > /*
> > * Timeout
On Thursday 12 April 2001 23:52, Andre Hedrick wrote:
> 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:
> */
> #defin
Andre Hedrick wrote:
>
> 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)
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:
> 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"
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
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
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
Mark Salisbury wrote:
>
> > I think it makes the most sense to keep jiffie as a simple unsigned
> > int. If we leave drivers, and other code as is they can deal with
> > single word (32 bit) values and get reasonable results. If we make HZ
> > too high (say 10,000 to get micro second resolution
On Fri, Apr 13, 2001 at 08:20:56AM -0400, Mark Salisbury wrote:
> inner loop, i.e. interrupt timer code should never have to convert from some
> real time value into number of decrementer ticks in order to set up the next
> interrupt as that requires devides (and 64 bit ones at that) in a tickless
> Great HZ always defines units of jiffies, but that is worthless if there
> is not a ruleset that tells me a value to divide by to return it to a
> specific quantity of time.
HZ obviously.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
> I think it makes the most sense to keep jiffie as a simple unsigned
> int. If we leave drivers, and other code as is they can deal with
> single word (32 bit) values and get reasonable results. If we make HZ
> too high (say 10,000 to get micro second resolution) we will start
> limiting the ma
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
On Thu, Apr 12, 2001 at 09:04:28PM -0700, Andre Hedrick wrote:
> On Thu, 12 Apr 2001, george anzinger wrote:
>
> > Actually we could do the same thing they did for errno, i.e.
> >
> > #define jiffies get_jiffies()
> > extern unsigned get_jiffies(void);
>
> > No, not really. HZ still defines th
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
> > > > >
"Eric W. Biederman" wrote:
>
> Andre Hedrick <[EMAIL PROTECTED]> writes:
>
> > On Thu, 12 Apr 2001, george anzinger wrote:
> >
> > > Actually we could do the same thing they did for errno, i.e.
> > >
> > > #define jiffies get_jiffies()
> > > extern unsigned get_jiffies(void);
> >
> > > No, not r
Andre Hedrick <[EMAIL PROTECTED]> writes:
> On Thu, 12 Apr 2001, george anzinger wrote:
>
> > Actually we could do the same thing they did for errno, i.e.
> >
> > #define jiffies get_jiffies()
> > extern unsigned get_jiffies(void);
>
> > No, not really. HZ still defines the units of jiffies a
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
On Thu, 12 Apr 2001, george anzinger wrote:
> Actually we could do the same thing they did for errno, i.e.
>
> #define jiffies get_jiffies()
> extern unsigned get_jiffies(void);
> No, not really. HZ still defines the units of jiffies and most all the
> timing is still related to it. Its just
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
Andre Hedrick wrote:
>
> 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
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
> 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
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.
> >
>
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
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:
>
> 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, 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
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 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
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
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
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
> 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
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
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
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
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
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
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
>
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
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
>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
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
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:
> >
> > 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:
>
> 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
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
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
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
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
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
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:
> > > 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.
> > 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
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
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
> 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
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
> 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
>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
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
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.
> > 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_
>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
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
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, 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, 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
> 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, 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
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, 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 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
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
> 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
> > > > 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
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
> 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 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
>> 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
1 - 100 of 113 matches
Mail list logo
