Messages in this thread | | | Date | Sun, 13 Aug 2000 00:55:00 +1000 | From | Andrew Morton <> | Subject | Re: [patch] lowlatency-2.4.0-test6-E2 |
| |
Ingo Molnar wrote: > > the newest version of the lowlatency patch can be downloaded from: > > http://www.redhat.com/~mingo/lowlatency-patches/lowlatency-2.4.0-test6-E2
Comments and testing results:
- Measured a 2 millisec hit in lat_tcp and 4 millisec in bw_tcp. This was in tasklet context :(
- The 5 millisec pc_keyb X startup thing is still there. My vote is to leave it alone.
- You need to add a reschedule in ipc/shm.c:shm_free(). Quintela's shm-stress will show why.
- mmap002 is killed by the VM when running `amlat' at 1024 Hz to create scheduling pressure.
This is changed behaviour: it does not happen without this patch.
- In swap_out_mm() it is not correct to restart the vma scan after scheduling. If the current vma will take over a millisec to scan, and there is a process being scheduled once per millisec, swap_out_mm will never terminate. This is fairly easy to demonstrate with mmap002.
The fix is to resume the scan from `vma->vm_start'.
- mmap002 sometimes hangs when run under scheduling pressure. Probably due to the above problem.
- Running Quintela's ipc001 and then running mmap002 causes 8 millisec scheduling holes.
- `lilo' hangs when run under scheduling pressure if there are a lot of dirty blocks on the device. fsync_dev() changes.
- If you run bonnie++ to create lots of slab cache entries and then run mmap002, the resulting call to kmem_cache_reap() causes basically unbounded scheduling delays. I observed ~6 millisecs. I didn't fix this either.
- The patch significantly worsens bonnie++ figures. The overall execution time went from 9:04 to 9:23 when run during 1024 Hz scheduling pressure. From 8:44 to 8:52 when run without scheduling pressure.
- 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/
| |