On Thu, Sep 13, 2012 at 09:06:10AM -0700, Tim Chen wrote:
> On Tue, 2012-09-11 at 12:05 +0100, Mel Gorman wrote:
>
> >
> > One *massive* change here that is not called out in the changelog is that
> > the reclaim path now holds the page lock on multiple pages at the same
> > time waiting for them
On Tue, 2012-09-11 at 12:05 +0100, Mel Gorman wrote:
>
> One *massive* change here that is not called out in the changelog is that
> the reclaim path now holds the page lock on multiple pages at the same
> time waiting for them to be batch unlocked in __remove_mapping_batch.
> This is suspicious
On Mon, 10 Sep 2012 09:19:25 -0700
Tim Chen wrote:
> @@ -1014,6 +1090,9 @@ keep_lumpy:
I worry that your tree has the label "keep_lumpy" in it! Are you
developing against recent kernels?
> VM_BUG_ON(PageLRU(page) || PageUnevictable(page));
> }
>
> + nr_reclaimed += __
On Mon, Sep 10, 2012 at 09:19:25AM -0700, Tim Chen wrote:
> We gather the pages that need to be unmapped in shrink_page_list. We batch
> the unmap to reduce the frequency of acquisition of
> the tree lock protecting the mapping's radix tree. This is
> possible as successive pages likely share the
Hi Tim,
On Mon, Sep 10, 2012 at 09:19:25AM -0700, Tim Chen wrote:
> We gather the pages that need to be unmapped in shrink_page_list. We batch
> the unmap to reduce the frequency of acquisition of
> the tree lock protecting the mapping's radix tree. This is
> possible as successive pages likely s
5 matches
Mail list logo
