Messages in this thread |  | | | From | KOSAKI Motohiro <> | | Subject | Re: Swappiness vs. mmap() and interactive response | | Date | Wed, 29 Apr 2009 14:51:07 +0900 (JST) |
| |
Hi
> On Tue, Apr 28, 2009 at 05:09:16PM +0800, Wu Fengguang wrote: > > The semi-drop-behind is a great idea for the desktop - to put just > > accessed pages to end of LRU. However I'm still afraid it vastly > > changes the caching behavior and wont work well as expected in server > > workloads - shall we verify this? > > > > Back to this big-cp-hurts-responsibility issue. Background write > > requests can easily pass the io scheduler's obstacles and fill up > > the disk queue. Now every read request will have to wait 10+ writes > > - leading to 10x slow down of major page faults. > > > > I reach this conclusion based on recent CFQ code reviews. Will bring up > > a queue depth limiting patch for more exercises.. > > We can muck with the I/O scheduler, but another thing to consider is > whether the VM should be more aggressively throttling writes in this > case; it sounds like the big cp in this case may be dirtying pages so > aggressively that it's driving other (more useful) pages out of the > page cache --- if the target disk is slower than the source disk (for > example, backing up a SATA primary disk to a USB-attached backup disk) > no amount of drop-behind is going to help the situation. > > So that leaves three areas for exploration: > > * Write-throttling > * Drop-behind > * background writes pushing aside foreground reads > > Hmm, note that although the original bug reporter is running Ubuntu > Jaunty, and hence 2.6.28, this problem is going to get *worse* with > 2.6.30, since we have the ext3 data=ordered latency fixes which will > write out the any journal activity, and worse, any synchornous commits > (i.e., caused by fsync) will force out all of the dirty pages with > WRITE_SYNC priority. So with a heavy load, I suspect this is going to > be more of a VM issue, and especially figuring out how to tune more > aggressive write-throttling may be key here.
firstly, I'd like to report my reproduce test result.
test environment: no lvm, copy ext3 to ext3 (not mv), no change swappiness, CFQ is used, userland is Fedora10, mmotm(2.6.30-rc1 + mm patch), CPU opteronx4, mem 4G
mouse move lag: not happend window move lag: not happend Mapped page decrease rapidly: not happend (I guess, these page stay in active list on my system) page fault large latency: happend (latencytop display >200ms)
Then, I don't doubt vm replacement logic now. but I need more investigate. I plan to try following thing today and tommorow.
- XFS - LVM - another io scheduler (thanks Ted, good view point) - Rik's new patch
|  |