>
>
> -
> 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/
--
/*
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
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
> &
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]
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
;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 System
00 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.
--
/*------
han 500 nanoseconds, 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 | Me
o effect 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 - Ker
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://vger.k
> 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
> 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
e interrupt 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
> 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
essage 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 - Ke
st: 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/
--
/***
** Mark
nsures 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]
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
user
> (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
the scope of this topic is
> really not fit 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.
--
/*-
> -
> 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/
--
/*-
(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 Sy
ors must 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.
--
/***
*
OS (all except the core of
the kernel) etc etc...
--
/*----**
** Mark Salisbury |[EMAIL PROTECTED] **
****
** "WYGIWYD - What You Get Is What You Deserve" **
**
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,
> Mar
crack.
--
/***
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - Kernel Team **
****
** "WYGIWYD - What You Get Is What
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
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
m big-endian in the VME based version.
--
/*--------**
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - Kernel Team **
****
-
To unsubscribe from this list: send t
29 matches
Mail list logo
