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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:27 EST