On 01/31/2008 01:36 AM, Jan Kiszka was caught saying:
> Jan Kiszka wrote:
>> George Anzinger wrote:
>>> On 01/30/2008 04:08 PM, Jan Kiszka was caught saying:
>>>> [Here comes a rebased version against latest x86/mm]
>>>>
>>>> In case "
SodaPop wrote:
>
> I too have noticed that nicing processes does not work nearly as
> effectively as I'd like it to. I run on an underpowered machine,
> and have had to stop running things such as seti because it steals too
> much cpu time, even when maximally niced.
>
> As an example, I can ru
Rik van Riel wrote:
>
> On Mon, 9 Apr 2001, george anzinger wrote:
> > SodaPop wrote:
> > >
> > > I too have noticed that nicing processes does not work nearly as
> > > effectively as I'd like it to. I run on an underpowered machine,
> >
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.
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.
&g
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
One rule of optimization is to move any code you can outside the loop.
Why isn't the nice_to_ticks calculation done when nice is changed
instead of EVERY recalc.? I guess another way to ask this is, who needs
to see the original nice? Would it be worth another task_struct entry
to move this cal
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
Hubertus Franke wrote:
>
> In the recent optimizations to sys_sched_yield a bug was introduced.
> In the current implementation of sys_sched_yield()
> the aligned_data and idle_tasks are indexed by logical cpu-#.
>
> They should however be indexed by physical cpu-#.
> Since logical==physical on
Walt Drummond wrote:
>
> george anzinger writes:
> > Uh... I do know about this map, but I wonder if it is at all needed.
> > What is the real difference between a logical cpu and the physical one.
> > Or is this only interesting if the machine is not Smp, i.e. all the c
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
> >
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
> > > wher
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
Any one know any thing about a POSIX draft 52 or 53 or 54. I think they
are suppose to have something to do with real time.
Where can they be found? What do they imply for the kernel?
George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
"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_jiff
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:
> &g
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
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 implement
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
Brian Gerst wrote:
>
> Mircea Damian wrote:
> >
> > Hello,
> >
> > I was expecting to receive some replies to my last desperate messages:
> > http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg35446.html
> > http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg36591.html
> >
> > M
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
Rik van Riel wrote:
>
> On Thu, 12 Apr 2001, Pavel Machek wrote:
>
> > > One rule of optimization is to move any code you can outside the loop.
> > > Why isn't the nice_to_ticks calculation done when nice is changed
> > > instead of EVERY recalc.? I guess another way to ask this is, who needs
>
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
"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
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
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
"Richard B. Johnson" wrote:
>
> It seems that the nature of schedule() has changed in recent
> kernels. I am trying to update my drivers to correspond to
> the latest changes. Here is an example:
>
> This waits for some hardware (interrupt sets flag), time-out in one
> second. This is in an ioct
george anzinger wrote:
>
> Marcus Ramos wrote:
> >
> > Hello,
> >
> > I am using usleep in an application under RH7 kernel 2.4.2. However,
> > when I bring its argument down to 20 miliseconds (20.000 microseconds)
> > or less, this seems to be ig
"Robert H. de Vries" wrote:
>
> On Monday 23 April 2001 19:45, you wrote:
>
> > By the way, is the user land stuff the same for all "arch"s?
>
> Not if you plan to handle the CPU cycle counter in user space. That is at
> least what I would propose.
Just got interesting, lets let the world look
Gabriel Paubert wrote:
>
> On Mon, 23 Apr 2001, george anzinger wrote:
>
> > "Robert H. de Vries" wrote:
> > >
> > > On Monday 23 April 2001 19:45, you wrote:
> > >
> > > > By the way, is the user land stuff the same for all &quo
I may be off base here, but the problem as described below does _NOT_
seem to be OT so I removed that from the subject line. A clock drift
change with an OS update is saying _something_ about the OS, not the
hardware. In this case it seems to be the 2.4.x OS that is loosing
time. I suspect the
Excuse me if I am off base here, but wouldn't an atomic operation be
better here. There are atomic inc/dec and add/sub macros for this. It
just seems that that is all that is needed here (from inspection of the
patch).
George
Rasmus Andersen wrote:
>
> On Mon, Jan 29, 2001 at 07:30:01PM -020
An open source project is starting at:
http://sourceforge.net/projects/high-res-timers/
Currently the project is collecting ideas, requirements, etc.
A mailing list has been set up for the project. To join:
http://lists.sourceforge.net/lists/listinfo/high-res-timers-discourse
To mail to the
Jamie wrote:
>
> Hi !
>
> I've been trying to determine the reliability of kernel timers when a box has been
>up for a while. Now as everyone is aware (for HZ=100 (default)), when the uptime of
>the kernel reaches (approx.) 1.3 years the clock tick count (jiffies) wraps-around.
>Now if a kern
"Richard B. Johnson" wrote:
>
> On Fri, 2 Mar 2001, Christopher Friesen wrote:
>
> > John Being wrote:
> >
> > > gives following result on box in question
> > > root@**:# ./clo
> > > Leap found: -1687 msec
> > > and prints nothing on all other my boxes.
> > > This gives me bunch of troubles
"Richard B. Johnson" wrote:
>
> On Fri, 2 Mar 2001, george anzinger wrote:
>
> > "Richard B. Johnson" wrote:
>
~snip~
> > > Note that two subsequent calls to gettimeofday() must not return the
> > > same time even if your CPU runs infi
Roger Larsson wrote:
>
> On Thursday 04 January 2001 09:43, ludovic fernandez wrote:
> > Daniel Phillips wrote:
> > > The key idea here is to disable preemption on spin lock and reenable on
> > > spin unlock. That's a practical idea, highly compatible with the
> > > current way of doing things.
ludovic fernandez wrote:
>
> george anzinger wrote:
>
> > Roger Larsson wrote:
> > >
> >
> > > This part can probably be put in a proper non inline function.
> > > Cache issues...
> > > +/*
> >
Andrew Morton wrote:
>
> Nigel Gamble wrote:
> >
> > Spinlocks should not be held for lots of time. This adversely affects
> > SMP scalability as well as latency. That's why MontaVista's kernel
> > preemption patch uses sleeping mutex locks instead of spinlocks for the
> > long held locks.
>
>
Nigel Gamble wrote:
>
> On Sat, 13 Jan 2001, Roger Larsson wrote:
> > A rethinking of the rescheduling strategy...
>
> Actually, I think you have more-or-less described how successful
> preemptible kernels have already been developed, given that your
> "sleeping spin locks" are really just sleep
"David S. Miller" wrote:
>
> Nigel Gamble writes:
> > That's why MontaVista's kernel preemption patch uses sleeping mutex
> > locks instead of spinlocks for the long held locks.
>
> Anyone who uses sleeping mutex locks is asking for trouble. Priority
> inversion is an issue I dearly hope we n
Roger Larsson wrote:
>
> On Sunday 14 January 2001 01:06, george anzinger wrote:
> > Nigel Gamble wrote:
> > > On Sat, 13 Jan 2001, Roger Larsson wrote:
> > > > A rethinking of the rescheduling strategy...
> > >
> > > Actually, I t
Anton Altaparmakov wrote:
> At 06:29 20/01/2001, Linus Torvalds wrote:
>
>> On Fri, 19 Jan 2001, Mark I Manning IV wrote:
>
> [snip]
>
>> > > And two spaces is not enough. If you write code that needs
>> comments at
>> > > the end of a line, your code is crap.
>> >
>> > Might i ask you to
Andrew Morton wrote:
>
> George Anzinger wrote:
> >
> > The notion of releasing a spin lock by initializing it seems IMHO, on
> > the face of it, way off. Firstly the protected area is no longer
> > protected which could lead to undefined errors/ crashes and s
I am trying to understand what is going on in the following code. The
reference for %2, i.e. "m"(*__xg(ptr)) seems like magic (from
.../include/i386/system.h). At the same time, the code "m" (*mem) from
the second __asm__ below (my code) seems to generate the required asm
code. Before I go with
Timur Tabi wrote:
>
> ** Reply to message from George Anzinger <[EMAIL PROTECTED]> on Wed, 15 Nov
> 2000 12:55:46 -0800
>
> > I am trying to understand what is going on in the following code. The
> > reference for %2, i.e. "m"(*__xg(ptr)) seems like m
"David S. Miller" wrote:
>
>Date:Wed, 8 Nov 2000 15:11:49 -0800
>From: Mike Kravetz <[EMAIL PROTECTED]>
>
>The following code in __wake_up_common() is then
>executed:
>
>if (best_exclusive)
>best_exclusive->state = TASK_RUNNING;
>
So what is a coder to do. We need to define the pi_mutex_trylock(). If
I understand this thread, it should return 0 on success. Is this
correct?
George
On Saturday 25 November 2000 22:05, Roger Larsson wrote:
> On Saturday 25 November 2000 20:22, Philipp Rumpf wrote:
> > On Sat, Nov 25, 20
"Amit S. Kale" wrote:
>
> George Anzinger wrote:
> > I took a look at this and it looks very messy. The whole notion is that
> > the stack is available to put the call on and then proceed. The
> > question then is what does the stack look like after the call
John Levon wrote:
>
> Am I right ? against test8pre1
>
> Also, is it a bug to not set TASK_{UN}INTERRUPTIBLE before doing a
> schedule_timeout() ? What will happen ?
>
Well, first the "timeout" call will return immediately. Next, when the
time out actually happens, if the task is not TASK_RUNN
Hubert Tonneau wrote:
>
> Benchmarking Pliant (http://pliant.cx/) semaphores led to unexpectedly
> low results. The problem to either kernel bad features or bugs in my
> program since Pliant uses no glue library such as glibc: it calls
> directly kernel funtions.
>
> Not enough scheduling proble
+ }
+ }
+ if (msg_level < console_loglevel && console_drivers) {
+ struct console *c = console_drivers;
+ while(c) {
+ if ((c->flags & CON_ENABLED) &&
John Levon wrote:
>
> On Wed, 6 Sep 2000, George Anzinger wrote:
>
> > John Levon wrote:
> > >
> > > Am I right ? against test8pre1
> > >
> > > Also, is it a bug to not set TASK_{UN}INTERRUPTIBLE before doing a
> > > schedule_timeo
Chris Wedgwood wrote:
>
> On Wed, Sep 06, 2000 at 12:52:29PM -0700, Linus Torvalds wrote:
>
> [... words of wisdom removed for brevity ...]
>
> I'm a bastard, and proud of it!
>
> Linus
>
> Anyone else think copyleft could make a shirt from this?
I like this
David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > So it seems to be a bug at least in terms of timing. Unfortunately I
> > only got about 4 replies to the patches that touched 20+ drivers. I
> > suppose I should just hassle maintainers until they fix it or tell me
> > where I've gone wrong
Rik van Riel wrote:
>
> On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> > On Wed, 6 Sep 2000, George Anzinger wrote:
> >
> > >The times a kernel is not preemptable under this patch are:
> > >
> > >While handling interrupts.
> > >While doing &
Dan Maas wrote:
>
> > I have a question about the time-slice of linux, how do I know it, or how
> > can I test it?
>
> First look for the (platform-specific) definition of HZ in
> include/asm/param.h. This is how many timer interrups you get per second (eg
> on i386 it's 100). Then look at inclu
Dear Linus,
As you know we at MontaVista are working on a fully preemptable kernel.
In this work we have come up with a couple of issues we would like your
comments on.
First, as you know, we have added code to the spinlock macros to count
up and down a preemption lock counter. We would like t
At line 1073 of ../drivers/char/i2lib.c (2.4.0-test9) we find:
WRITE_LOCK_IRQSAVE(...
this is followed by:
COPY_FROM_USER(...
It seems to me that this could result in a page fault with interrupts
off. Is this ok?
George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel
Alan Cox wrote:
>
> > At line 1073 of ../drivers/char/i2lib.c (2.4.0-test9) we find:
> >
> > WRITE_LOCK_IRQSAVE(...
> >
> > this is followed by:
> >
> > COPY_FROM_USER(...
> >
> > It seems to me that this could result in a page fault with interrupts
> > off. Is this ok?
>
> It wont do what you
Anonymous wrote:
>
> In the Linux scheduler they use a circular queue implementation with round
> robin. What is the advantage of this over just using a normal queue with a
> back and front. Also does anyone know what a test plan for such a design
> would even begin to look like. This is a projec
Linus,
In doing the full preemption testing we found and fixed this little
segfault window. Seems that interrupts are left on for the page fault.
This allows an interrupt prior to fetching the faulting info from CR2.
Result, illegal memory reference, i.e. segfault. I don't know what
interrupt
But, here the customer did run the configure code (he said he did not
change anything). Isn't this where the machine should be diagnosed and
the right options chosen? Need a way to say it is a cross build, but
that shouldn't be too hard.
My $.02 worth.
George
"James A. Sutherland" wrote:
>
"James A. Sutherland" wrote:
>
> On Wed, 08 Nov 2000, George Anzinger wrote:
> > But, here the customer did run the configure code (he said he did not
> > change anything). Isn't this where the machine should be diagnosed and
> > the right options chosen?
Andi Kleen wrote:
>
> On Thu, Nov 09, 2000 at 12:27:29PM +1300, david wrote:
> >
> > 2 . put the save / restore code in my code (NOT! GOOD! i do not wont to
> > do it this way it is not the right way)
>
> It is the right way because it only penalizes your code, not everybody else.
>
This is a M
Chris Swiedler wrote:
>
> Is it possible to get a process's name / full execution path (from
> kernelspace) given only a task struct? I can't find any pointers to this
> information in the task struct, and I don't know where else it might be. ps
> seems to be able to get the process name, but tha
I thought this would be simple, but...
Could someone point me at the info on calling conventions to be used
with
x86 processors. I need this to write asm code correctly and I suspect
that it is a bit more formal than the various comments I have found in
the sources. Is it, perhaps an Intel doc?
Dan Aloni wrote:
>
> On Thu, 9 Nov 2000, Ivan Passos wrote:
>
> > Where in the src tree can I find (or what is) the command to generate a
> > patch file from two Linux kernel src trees, one being the original and the
> > other being the newly changed one??
>
> The syntex looks like this one:
>
The notion of releasing a spin lock by initializing it seems IMHO, on
the face of it, way off. Firstly the protected area is no longer
protected which could lead to undefined errors/ crashes and secondly,
any future use of spinlocks to control preemption could have a lot of
trouble with this, pri
Dan Aloni wrote:
>
> On Fri, 10 Nov 2000, George Anzinger wrote:
>
> > > 4 kernel trees, one after make dep ; make bzImage, and all taking together
> > > just 193MB, instead of about 400MB... hard links, gotta love'em.
> >
> > Ok, this is cool, bu
In looking over sched.c I find:
spin_lock_irq(&runqueue_lock);
read_lock(&tasklist_lock);
This seems to me to be the wrong order of things. The read lock
unavailable (some one holds a write lock) for relatively long periods of
time, for example, wait holds it in a while loop.
's scheduling policy.
Yes, I think this is true. The runqueue_lock should only be needed
after the error checks. Still, the error checks don't take all that
long...
George
> -
> Mike
>
> On Thu, Dec 07, 2000 at 03:07:18PM -0800, george anzinger wrote:
> > In looki
Jason Wohlgemuth wrote:
>
> In an effort to stay consistent with the community, I migrated some code
> to a driver to use the daemonize() routine in the function specified by
> the kernel_thread() call.
>
> However, in looking at a few drivers in the system (drivers/usb/hub.c ,
> drivers/md/md.c
Russell King wrote:
>
> Rogier Wolff writes:
> > Alan Cox wrote:
> > > What better interactivity ;)
> > Thus to me, 2.4 FEELS much less interactive. When I move windows they
> > don't follow the mouse in real-time.
>
> Interesting observation: in a scrolling rxvt, kernel 2.0 is smoother than
> 2
Alan Cox wrote:
>
> > Both of these methods have problems, especially with the proposed
> > preemptions changes. The first case causes the thread to run with the
> > BKL for the whole time. This means that any other task that wants the
> > BKL will be blocked. Surly the needed protections don'
Andrew Morton wrote:
>
> It's been quiet around here lately...
>
> This is a rework of the 2.4 wakeup code based on the discussions Andrea
> and I had last week. There were two basic problems:
>
> - If two tasks are on a waitqueue in exclusive mode and one gets
> woken, it will put itself ba
As you know we at MontaVista are working on a preemptable kernel that
takes advantage of the spin_lock() macros. One of the "tricks" we use
is to bump a preemption counter on a spin_lock() and to decrement it on
spin_unlock(). The question, here posed, has to do with the test that
needs to be do
Where is the internal interface to procfs documented?
George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
5 Oct 2000, George Anzinger wrote:
> > Where is the internal interface to procfs documented?
>
> There is no documentation for the -exported- procfs interface as far as
> I know. As for internal interfaces, who knows what you are asking...
>
> Here's a rough outline: (
Rik van Riel wrote:
>
> On Thu, 8 Mar 2001, Boris Dragovic wrote:
>
> > > Of course. Now we just need the code to determine when a task
> > > is holding some kernel-side lock ;)
> >
> > couldn't it just be indicated on actual locking the resource?
>
> It could, but I doubt we would want this o
Michael Reinelt wrote:
>
> Hi,
>
> I've got a question regarding the nanosleep() system call.
>
> I'm writing a little tool called lcd4linux
> (http://lcd4linux.sourceforge.net), where I have to drive displays
> connected to the parallel port. I'm doing this in userland, using
> outb().
>
> So
Michael Reinelt wrote:
>
> george anzinger wrote:
> >
> > Michael Reinelt wrote:
> > >
> > > At the moment I implemented by own delay loop using a small assembler
> > > loop similar to the one used in the kernel. This has two disadvantages:
> >
Keith Owens wrote:
>
> On Sun, 11 Mar 2001 08:44:24 +0100 (CET),
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >Andrew,
> >
> >your patch looks too complex, and doesnt cover the case of the serial
> >driver deadlocking. Why not add a "touch_nmi_watchdog_counter()" function
> >that just changes last_
Keith Owens wrote:
>
> On Sun, 11 Mar 2001 20:43:16 -0800,
> george anzinger <[EMAIL PROTECTED]> wrote:
> >Consider this. Why not use the NMI to sync the cpus. Kdb would have a
> >function that is called each NMI.
>
> kdb uses NMI IPI to get the other cpu'
Rik van Riel wrote:
>
> On Wed, 14 Mar 2001, Martin Dalecki wrote:
>
> > Not the embedded folks!!! The server folks laugh histerically all
> > times they go via ssh to a trashing busy box to see what's wrong and
> > then they see top or ps auxe under linux never finishing they job:
>
> That's a
Rik van Riel wrote:
>
> On Wed, 14 Mar 2001, george anzinger wrote:
>
> > Is it REALLY necessary to prevent them from seeing an
> > inconsistent state? Seems to me that in the total picture (i.e.
> > system wide) they will never see a consistent state, so why be
At https://high-res-timers.sourceforge.net we are trying to define a
high resolution timer patch for linux (please join us if you are
interested). We would like to know who wrote the time list management
code that is currently in the kernel.
Or
Any help on any studies done on the nature of the
Dawson Engler wrote:
>
> > Is it difficult to split it into "interrupts disabled" and "spin lock
> > held"?
>
Is it difficult to test for matching spinlock pairs such as
spin_lock_irq/spin_unlock_irq. Sometimes a spin_lock_irq is followed by
a spin_unlock and a separate interrupt re-enable. Th
Nigel Gamble wrote:
>
> On Tue, 20 Mar 2001, Roger Larsson wrote:
> > One little readability thing I found.
> > The prev->state TASK_ value is mostly used as a plain value
> > but the new TASK_PREEMPTED is or:ed together with whatever was there.
> > Later when we switch to check the state it is c
Nigel Gamble wrote:
>
> On Wed, 21 Mar 2001, Keith Owens wrote:
> > I misread the code, but the idea is still correct. Add a preemption
> > depth counter to each cpu, when you schedule and the depth is zero then
> > you know that the cpu is no longer holding any references to quiesced
> > struct
Parity Error wrote:
>
> instead of need_reshed being a per-task flag, could it be
> as a global flag ?, since every time current->need_reshed
> is checked, schedule() is just called to pick another
> process.
>
> ---
But for which cpu? Really this is a short cut to provide a per cpu area
that I
What happens if you just make swap VERY large? Does the system thrash
it self to a virtual standstill? Is this a possible answer? Supposedly
you could then sneak in and blow away the bad guys manually ...
George
Paul Jakma wrote:
>
> On Fri, 23 Mar 2001, Szabolcs Szakacsits wrote:
>
> > Abo
Dipankar Sarma wrote:
>
> Nigel Gamble wrote:
> >
> > On Wed, 21 Mar 2001, Keith Owens wrote:
> > > I misread the code, but the idea is still correct. Add a preemption
> > > depth counter to each cpu, when you schedule and the depth is zero then
> > > you know that the cpu is no longer holding a
Rusty Russell wrote:
>
> In message <[EMAIL PROTECTED]> you write:
> > Here is an attempt at a possible version of synchronize_kernel() that
> > should work on a preemptible kernel. I haven't tested it yet.
>
> It's close, but...
>
> Those who suggest that we don't do preemtion on SMP make thi
Nigel Gamble wrote:
>
> On Sat, 31 Mar 2001, george anzinger wrote:
> > I think this should be:
> > if (p->has_cpu || p->state & TASK_PREEMPTED)) {
> > to catch tasks that were preempted with other states.
>
> But the other states are all
Joe deBlaquiere wrote:
~snip~
> The locical answer is run with HZ=1 so you get 100us intervals,
> right ;o).
Lets not assume we need the overhead of HZ=1 to get 100us
alarm/timer resolution. How about a timer that ticks when we need the
next tick...
On systems with multiple hardwa
P: George Anzinger
M: george@mvista.com
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
S: Supported
I don't really know about the rest of them, but I think this should be:
L: linux-kernel@vger.kernel.org
Least wise that is where I look...
~
--
George Anzinger george@mvista.com
Horms wrote:
On Tue, Apr 12, 2005 at 12:14:56PM -0700, George Anzinger wrote:
Horms wrote:
Use netdev as the mailing list contact instead of the mostly dead
linux-net list.
~
PHRAM MTD DRIVER
@@ -1795,7 +1795,7 @@
POSIX CLOCKS and TIMERS
P: George Anzinger
M: george@mvista.com
-L
but rather an argumentation of the
help text that goes with it. For those who want timers to repeat at one second
(or multiples there of) this is useful info.
For you enjoyment I have attached the program used to print this. It allows you
to try additional values...
--
George Anzinge
r really is in the
range of 848ppm for HZ=1000 BECAUSE we need to follow the standard. You can
easily see this with the current 2.6 kernel. We even have a bug report on it:
http://bugzilla.kernel.org/show_bug.cgi?id=3289
~
--
George Anzinger george@mvista.com
HRT (High-res-timers
1 - 100 of 225 matches
Mail list logo
