On Thu, Aug 18, 2011 at 04:54:20PM -0700, Andrew Morton wrote: > On Wed, 10 Aug 2011 11:47:13 +0100 > Mel Gorman <mgorman@xxxxxxx> wrote: > > > The new problem is that > > reclaim has very little control over how long before a page in a > > particular zone or container is cleaned which is discussed later. > > Confused - where was this discussed? Please tell us more about > this problem and how it was addressed. > This text really referred to V2 of the series where kswapd was not writing back pages. This lead to problems on NUMA as described in https://lkml.org/lkml/2011/7/21/242 . I should have updated the text to read "There is a potential new problem as reclaim has less control over how long before a page in a particularly zone or container is cleaned and direct reclaimers depend on kswapd or flusher threads to do the necessary work. However, as filesystems sometimes ignore direct reclaim requests already, it is not expected to be a serious issue" > Another (and somewhat interrelated) potential problem I see with this > work is that it throws a big dependency onto kswapd. If kswapd gets > stuck somewhere for extended periods, there's nothing there to perform > direct writeback. In theory, this is true. In practice, btrfs and ext4 are already ignoring requests from direct reclaim and have been for some time. btrfs is particularly bad in that is also ignores requests from kswapd leading me to believe that we are eventually going to see stall-related bug reports on large NUMA machines with btrfs. > This has happened in the past in weird situations > such as kswpad getting blocked on ext3 journal commits which are > themselves stuck for ages behind lots of writeout which itself is stuck > behind lots of reads. That's an advantage of direct reclaim: more > threads available. I do not know what these situations were but was it possible that it was due to too many direct reclaimers starving kswapd of access to the journal? > How forcefully has this stuff been tested with multiple disks per > kswapd? As heavily as I could on the machine I had available. This was 4 disks for one kswapd instance. I did not spot major problems. > Where one disk is overloaded-ext3-on-usb-stick? > I tested with ext4 on a USB stick, not ext3. It completed faster and the interactive performance felt roughly the same. -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>