Hi,
Time to repeat a email?
This is the patch that made 2.2.10 + lowlatency stable.
I thought it or something better was integrated by now.
But I checked an found nothing...
I do not have the source for 2.2.14 downloaded
but the line should be very close to 153 after
applying the lowlatency patch.
Note: I have not tested it with 2.2.14!!!
/RogerL
Roger Larsson wrote:
>
> Hi,
>
> This is from an email sent to Ingo.
>
> First I patched the system with N5.
> Backed out patches to shm.c and vmscan.c
> [vmscan.c should not be necessary to back out,
> Ingo says N6 version is safe, and the changes
> from N5 made no difference => N5 safe?]
> Modified Ingos patch as below [UGLY but functional].
>
> And run this, and never got a lockup.
> (Even together with my latency-profiling-2.2.10-r5.patch)
>
> I have since then backed out to a standard 2.2.10 kernel
> to be able to find another sound related problem.
>
> /RogerL
>
> The code is from function shrink_mmap
> linux/mm/filemap.c:153
>
> Roger Larsson wrote:
> >
> > Hi Ingo,
> >
> > By enclosing the conditional_schedule in filemap.c with
> > the following. I get better latency and no lockups.
> >
> > unsigned long save_clock = clock;
> > conditional_schedule();
> > if (save_clock != clock) {
> > // Was run during sleep by higher prio process
> > // it should have succeeded...
> > return 1;
> > }
> >
>
> ------------------------------------------------------------------------
>
> Subject: [patch] lowlatencies N5 lockup bug
> Date: Wed, 04 Aug 1999 10:40:33 +0200
> From: Roger Larsson <nra02596@norran.net>
> To: Ingo Molnar <mingo@chiara.csoma.elte.hu>
>
> Hi Ingo,
>
> By enclosing the conditional_schedule in filemap.c with
> the following. I get better latency and no lockups.
>
> unsigned long save_clock = clock;
> conditional_schedule();
> if (save_clock != clock) {
> // Was run during sleep by higher prio process
> // it should have succeeded...
> return 1;
> }
>
> Note: I have not readded shm.c and vmscan.c patch yet, since shm.c
> is said to cause OOPS - but I fail to see how.
> Could you explain it please.
>
> But it is easy to explain how this bug could cause them.
> low prio process at end of memory, intercepted by high prio,
> high prio reenters, clock wraps, leaves, return to low prio
> continues - now clock can step a long way before next
> sync (at next wrap), pointer page is far off...
>
> /RogerL
-- Home page: http://www.norran.net/nra02596/
attached mail follows:
Hi,
This is from an email sent to Ingo.
First I patched the system with N5. Backed out patches to shm.c and vmscan.c [vmscan.c should not be necessary to back out, Ingo says N6 version is safe, and the changes from N5 made no difference => N5 safe?] Modified Ingos patch as below [UGLY but functional].
And run this, and never got a lockup. (Even together with my latency-profiling-2.2.10-r5.patch)
I have since then backed out to a standard 2.2.10 kernel to be able to find another sound related problem.
/RogerL
The code is from function shrink_mmap linux/mm/filemap.c:153
Roger Larsson wrote: > > Hi Ingo, > > By enclosing the conditional_schedule in filemap.c with > the following. I get better latency and no lockups. > > unsigned long save_clock = clock; > conditional_schedule(); > if (save_clock != clock) { > // Was run during sleep by higher prio process > // it should have succeeded... > return 1; > } >
attached mail follows:
Hi Ingo,
By enclosing the conditional_schedule in filemap.c with the following. I get better latency and no lockups.
unsigned long save_clock = clock; conditional_schedule(); if (save_clock != clock) { // Was run during sleep by higher prio process // it should have succeeded... return 1; }
Note: I have not readded shm.c and vmscan.c patch yet, since shm.c is said to cause OOPS - but I fail to see how. Could you explain it please.
But it is easy to explain how this bug could cause them. low prio process at end of memory, intercepted by high prio, high prio reenters, clock wraps, leaves, return to low prio continues - now clock can step a long way before next sync (at next wrap), pointer page is far off...
/RogerL
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:31 EST