[lkml]   [2009]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Bug #14141] order 2 page allocation failures in iwlagn
    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

    > 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.


    [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 linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-10-25 19:57    [W:0.022 / U:25.184 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site