Messages in this thread | | | Date | Sat, 05 Aug 2000 09:06:04 +1000 | From | Andrew Morton <> | Subject | Re: [patch] lowlatency patch for 2.4, lowlatency-2.4.0-test6-B5 |
| |
yodaiken@fsmlabs.com wrote: > > On Fri, Aug 04, 2000 at 03:43:15PM +0200, Ingo Molnar wrote: > > *no*. There are places in the kernel that do work for millisecs while > > holding a spinlock. This causes millisec latencies even if we had a > > The interesting question here is "why"? The only example ever discussed > here was copying data on big reads/writes and this seems like a classic > case of where the algorithm needs to be fixed -- if you have a millisecond > copy then you almost certainly would benefit from kiobufs or something smart.
The only expensive one which of which I'm aware is the lock in zap_page_range(): "This is a long-lived spinlock.".
My approach here was to bust zap_page_range() up into 512-page chunks with one reschedule per chunk. Ingo's patch does this on a per-page basis: tests need_resched and then, if required, drops the lock and reschedules.
- 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/
| |