Sorry for the delayed reply. On Monday 19 October 2009, Chris Mason wrote: > On Mon, Oct 19, 2009 at 03:01:52PM +0100, Mel Gorman wrote: > > > During the 2nd phase I see the first SKB allocation errors with a > > > music skip between reading commits 95.000 and 110.000. > > > About commit 115.000 there is a very long pause during which the > > > counter does not increase, music stops and the desktop freezes > > > completely. The first 30 seconds of that freeze there is only very > > > low disk activity (which seems strange); > > > > I'm just going to have to depend on Jens here. Jens, the > > congestion_wait() is on BLK_RW_ASYNC after the commit. Reclaim usually > > writes pages asynchronously but lumpy reclaim actually waits of pages > > to write out synchronously so it's not always async. > > Waiting doesn't make it synchronous from the elevator point of view ;) > If you're using WB_SYNC_NONE, it's a async write. WB_SYNC_ALL makes it > a sync write. I only see WB_SYNC_NONE in vmscan.c, so we should be > using the async congestion wait. (the exception is xfs which always > does async writes). > > But I'm honestly not 100% sure. Looking back through the emails, the > test case is doing IO on top of a whole lot of things on top of > dm-crypt? I just tried to figure out if dm-crypt is turning the async > IO into sync IOs, but didn't quite make sense of it. > > Could you also please include which filesystems were being abused during > the test and how? Reading through the emails, I think you've got: > > gitk being run 3 times on some FS (NFS?) gitk is run on an ext3 logical volume in a volume group that's on a LUKS encrypted partition of the local hard disk. So it's: SATA harddisk -> dm-crypt (dmsetup) -> LVM (lvm2) -> ext3 > streaming reads on NFS Correct. My music share is a remote (nfs4) read-only mounted ext3 partition. > swap on dm-crypt Correct. Swap is another logical volume in the same volume group as mentioned above. So kcrypt gets to (de)encrypt both the gitk data *and* any swapping caused by that [1]. > If other filesystems are being used, please correct me. Also please > include if they are on crypto or straight block device. All my file systems are ext3. Nothing newfangled or exotic ;-) There are some bind mounts involved, but I expect that's transparent. Cheers, FJP [1] I've plans to move some of my data outside the encrypted volume, but currently everything except /boot is in the encrypted VG. -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
