an in the VME based version.
--
/*----**
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - Kernel Team **
****
-
To unsubscribe from this list: send the lin
.
--
/***
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - Kernel Team **
****
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
rnel
it too fscked up to deal with a small swap file.
--
/*--------**
** Mark Salisbury | Mercury Computer Systems**
***/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
with a small swap file.
--
/***
** Mark Salisbury | Mercury Computer Systems**
***/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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/
--
/*---
t for this mailing list.
funny, I could swear that RAD was an acronym for Rapid Application Development
as opposed to your farcical interpretation.
you complain about other people being hateful, but as I read it you threw the
first fireball.
--
/*------
ould swear that RAD was an acronym for Rapid Application Development
as opposed to your farcical interpretation.
you complain about other people being hateful, but as I read it you threw the
first fireball.
--
/*----**
** Mark Salisbury | Mercur
> (i.e. we will take a percent of the interrupts and record the untaken
> interrupts as overruns).
see my earlier e-mail, although it is a simple matter to enforce a minimum
allowable interval by parameter checking.
>
> What the project will NOT do:
>
> This project will NOT prov
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 an
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
lockup
r resolution VIRTUAL or PROFILE timers.
as I said, there are some kool things we could do here, and we should design in
allowances for future upgrades which implement these things and let it get done
as a followon.
--
/*--
ensures that even a flood of
POSIX timers with very short repeat intervals will be handled cleanly.
I will get more detailed comments to you tomorrow.
Mark Salisbury
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
nsubscribe 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/
--
/***
** Mark Salisbury | Merc
Q at http://www.tux.org/lkml/
--
/*----**
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - Kernel Team **
****
** I will be riding in the Multiple Sclerosis**
of
POSIX timers with very short repeat intervals will be handled cleanly.
I will get more detailed comments to you tomorrow.
Mark Salisbury
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
e to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
/***
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - Kernel
> 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
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 max
AQ at http://www.tux.org/lkml/
--
/*----**
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - Kernel Team **
****
** I will be riding in the Multiple Sclerosis**
** Great Mass Getaway, a 150 mil
errupt happened
till you get to the reload line because the int may have been masked or lower
pri than another interrupt.
also, why handle 1000's of interrupts if you only need to handle 10?
--
/***
** Mark Salisbury | Mercury Computer S
happened
till you get to the reload line because the int may have been masked or lower
pri than another interrupt.
also, why handle 1000's of interrupts if you only need to handle 10?
--
/***
** Mark Salisbury | Mercury Computer Systems
> 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
>
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, I
> 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
rs depending on the jiffie abstraction
can be supported without modification no matter what the configuration.
Mark Salisbury
-
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://vge
ect on the number of timer
interrupts because they generally never get hit. and when they do, you have to
pay the price anyway.
--
/***
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - Kernel T
onds, but
possibly up to 20,000,500 nanoseconds. this is because the maximum legal POSIX
time resolution is 20,000,000 nanoseconds (1/50th second or 50hz because of
european electricity and old hardware)
--
/*----**
** Mark Salisbury | Mercury Computer
0 to 1,000,000 improvement in resolution for timed events, and
the clock overhead after the change was about the same. (+-10% depending on
underlying CPU)
this is on a system that only had one clock tick per process quantum, as
opposed to the 10 in linux.
--
/*--------
I've been
> doing some of this already, both as a kernel patch and as part
> of RTAI; search for 'timekeeper' in the LKML archives if interested.
>
>
>
>
> dave...
--
/*--------**
** Mark Salisbury | Mercury Computer Systems**
** [E
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.
--
/*----**
** Mark Salisbury | Mercury C
be replaced easily enough w/ a macro such as
#define jiffies (get_time_in_jiffies())
then driver code would not need to be touched.
--
/*----**
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED]
handler.
On Tue, 10 Apr 2001, Andi Kleen wrote:
> 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
> &
handler.
On Tue, 10 Apr 2001, Andi Kleen wrote:
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
such as
#define jiffies (get_time_in_jiffies())
then driver code would not need to be touched.
--
/***
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - Kernel Team
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.
--
/***
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL
, both as a kernel patch and as part
of RTAI; search for 'timekeeper' in the LKML archives if interested.
dave...
--
/***
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - Kernel Team
the change was about the same. (+-10% depending on
underlying CPU)
this is on a system that only had one clock tick per process quantum, as
opposed to the 10 in linux.
--
/***
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL
bly up to 20,000,500 nanoseconds. this is because the maximum legal POSIX
time resolution is 20,000,000 nanoseconds (1/50th second or 50hz because of
european electricity and old hardware)
--
/*----**
** Mark Salisbury | Mercury Computer Systems**
*
on the number of timer
interrupts because they generally never get hit. and when they do, you have to
pay the price anyway.
--
/***
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - Kernel Team
without modification no matter what the configuration.
Mark Salisbury
-
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 FA
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 we
sysclock" timer interrupt per process quantum
instead of 10.
--
/*----**
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - Kernel Team **
****
** I will be riding in
>
> -
> 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/
--
/*--
TED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
/*----**
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - K
tead of 10.
--
/*----**
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - Kernel Team **
****
** I will be riding in the Multiple Sclerosis**
** Great Mass Getaway, a 150 mile bike
t be equivalent)
so the question in simple terms might phrased as:
is the API under GPL, or is it the code or are both?
I think the answer is both.
--
/*----**
** Mark S
, or is it the code or are both?
I think the answer is both.
--
/***
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | **
****
** "WY
On Tue, 17 Oct 2000, David Weinehall wrote:
> On Tue, Oct 17, 2000 at 08:14:58AM -0400, Mark Salisbury wrote:
> >
> > On Mon, 16 Oct 2000, [EMAIL PROTECTED] wrote:
> > > On Tue, 17 Oct 2000, Mikael Pettersson wrote:
> >
> > > Why Intel chose family 15
On Tue, 17 Oct 2000, David Weinehall wrote:
On Tue, Oct 17, 2000 at 08:14:58AM -0400, Mark Salisbury wrote:
On Mon, 16 Oct 2000, [EMAIL PROTECTED] wrote:
On Tue, 17 Oct 2000, Mikael Pettersson wrote:
Why Intel chose family 15 is still beyond me though.
IV is 15 if you just
crack.
--
/***
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - Kernel Team **
****
** "WYGIWYD - What You Get Is What
.
--
/***
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - Kernel Team **
****
** "WYGIWYD - What You Get Is What You De
didn't say I wanted to do it, just that it could be done.
my point was that a god-awful 365 message flamewar was unnecessary, and
removing C++ keywords from system headers is not that big a deal.
On Mon, 16 Oct 2000, Keith Owens wrote:
> On Mon, 16 Oct 2000 08:50:24 -0400,
> Mark Sal
ll except the core of
the kernel) etc etc...
--
/*--------**
** Mark Salisbury |[EMAIL PROTECTED] **
****
** "WYGIWYD - What You Get Is What You Deserve" **
**-
(void){}
simply breaking up this printk up into several smaller printk's solves the
problem.
I guess this is only a problem if you use cscope, but I thought you all would
like to know..
Mark
/***
** Mark Salisbury | Mercury Computer Systems
(void){}
simply breaking up this printk up into several smaller printk's solves the
problem.
I guess this is only a problem if you use cscope, but I thought you all would
like to know..
Mark
/***
** Mark Salisbury | Mercury Computer Systems
55 matches
Mail list logo
