From: Johannes Weiner <hannes@cmpxchg.org> To: Vlastimil Babka <vbabka@suse.cz> Cc: linux-mm@kvack.org, Andi Kleen <andi@firstfloor.org>, Andrea Arcangeli <aarcange@redhat.com>, Andrew Morton <akpm@linux-foundation.org>, Greg Thelen <gthelen@google.com>, Christoph Hellwig <hch@infradead.org>, Hugh Dickins <hughd@google.com>, Jan Kara <jack@suse.cz>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>, Mel Gorman <mgorman@suse.de>, Minchan Kim <minchan.kim@gmail.com>, Peter Zijlstra <peterz@infradead.org>, Rik van Riel <riel@redhat.com>, Michel Lespinasse <walken@google.com>, Seth Jennings <sjenning@linux.vnet.ibm.com>, Roman Gushchin <klamm@yandex-team.ru>, Ozgun Erdogan <ozgun@citusdata.com>, Metin Doslu <metin@citusdata.com>, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [patch 8/9] mm: thrash detection-based file cache sizing Date: Mon, 12 Aug 2013 12:27:40 -0400 [thread overview] Message-ID: <20130812162740.GS715@cmpxchg.org> (raw) In-Reply-To: <520808D1.70705@suse.cz> Hello Vlastimil! On Sun, Aug 11, 2013 at 11:57:37PM +0200, Vlastimil Babka wrote: > On 08/07/2013 12:44 AM, Johannes Weiner wrote: > >To accomplish this, a per-zone counter is increased every time a page > >is evicted and a snapshot of that counter is stored as shadow entry in > >the page's now empty page cache radix tree slot. Upon refault of that > >page, the difference between the current value of that counter and the > >shadow entry value is called the refault distance. It tells how many > >pages have been evicted from the zone since that page's eviction, > This explanation of refault distance seems correct... > >which is how many page slots are missing from the zone's inactive list > >for this page to get accessed twice while in memory. > But this part seems slightly incorrect. IMHO the correct formulation > would be "...how many page slots are AT MOST missing...". See below. Yes, I think this would be better phrasing. > >If the number of > >missing slots is less than or equal to the number of active pages, > >increasing the inactive list at the cost of the active list would give > >this thrashing set a chance to establish itself: > > > >eviction counter = 4 > > evicted inactive active > > Page cache data: [ a b c d ] [ e f g h i j k ] [ l m n ] > > Shadow entries: 0 1 2 3 > >Refault distance: 4 3 2 1 > Consider here that if 'd' was now accessed before 'c', I think 'e' > would be evicted and eviction counter would be incremented to 5. So > for 'c' you would now say that three slots would prevent the > refault, but in fact two would still be sufficient. This potential > imprecision could make the algorithm challenge more active pages > than it should, but I am not sure how bad the consequences could > be... so just pointing it out. Yes, pages are not accessed in strict order all the time and there is very much the occasional outlier that gets accessed before its peers. In fact, the code treats it as an AT MOST already. Every page fault is evaluated based on its refault distance, but a refault distance of N does not mean that N pages are deactivated. Only one page is. An outlier is thus harmless but we catch if a whole group of pages is thrashing. The changelog and documentation should be updated, thanks for pointing this out.
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org> To: Vlastimil Babka <vbabka@suse.cz> Cc: linux-mm@kvack.org, Andi Kleen <andi@firstfloor.org>, Andrea Arcangeli <aarcange@redhat.com>, Andrew Morton <akpm@linux-foundation.org>, Greg Thelen <gthelen@google.com>, Christoph Hellwig <hch@infradead.org>, Hugh Dickins <hughd@google.com>, Jan Kara <jack@suse.cz>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>, Mel Gorman <mgorman@suse.de>, Minchan Kim <minchan.kim@gmail.com>, Peter Zijlstra <peterz@infradead.org>, Rik van Riel <riel@redhat.com>, Michel Lespinasse <walken@google.com>, Seth Jennings <sjenning@linux.vnet.ibm.com>, Roman Gushchin <klamm@yandex-team.ru>, Ozgun Erdogan <ozgun@citusdata.com>, Metin Doslu <metin@citusdata.com>, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [patch 8/9] mm: thrash detection-based file cache sizing Date: Mon, 12 Aug 2013 12:27:40 -0400 [thread overview] Message-ID: <20130812162740.GS715@cmpxchg.org> (raw) In-Reply-To: <520808D1.70705@suse.cz> Hello Vlastimil! On Sun, Aug 11, 2013 at 11:57:37PM +0200, Vlastimil Babka wrote: > On 08/07/2013 12:44 AM, Johannes Weiner wrote: > >To accomplish this, a per-zone counter is increased every time a page > >is evicted and a snapshot of that counter is stored as shadow entry in > >the page's now empty page cache radix tree slot. Upon refault of that > >page, the difference between the current value of that counter and the > >shadow entry value is called the refault distance. It tells how many > >pages have been evicted from the zone since that page's eviction, > This explanation of refault distance seems correct... > >which is how many page slots are missing from the zone's inactive list > >for this page to get accessed twice while in memory. > But this part seems slightly incorrect. IMHO the correct formulation > would be "...how many page slots are AT MOST missing...". See below. Yes, I think this would be better phrasing. > >If the number of > >missing slots is less than or equal to the number of active pages, > >increasing the inactive list at the cost of the active list would give > >this thrashing set a chance to establish itself: > > > >eviction counter = 4 > > evicted inactive active > > Page cache data: [ a b c d ] [ e f g h i j k ] [ l m n ] > > Shadow entries: 0 1 2 3 > >Refault distance: 4 3 2 1 > Consider here that if 'd' was now accessed before 'c', I think 'e' > would be evicted and eviction counter would be incremented to 5. So > for 'c' you would now say that three slots would prevent the > refault, but in fact two would still be sufficient. This potential > imprecision could make the algorithm challenge more active pages > than it should, but I am not sure how bad the consequences could > be... so just pointing it out. Yes, pages are not accessed in strict order all the time and there is very much the occasional outlier that gets accessed before its peers. In fact, the code treats it as an AT MOST already. Every page fault is evaluated based on its refault distance, but a refault distance of N does not mean that N pages are deactivated. Only one page is. An outlier is thus harmless but we catch if a whole group of pages is thrashing. The changelog and documentation should be updated, thanks for pointing this out. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-08-12 16:28 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-08-06 22:44 [patch 0/9] mm: thrash detection-based file cache sizing v3 Johannes Weiner 2013-08-06 22:44 ` Johannes Weiner 2013-08-06 22:44 ` [patch 1/9] lib: radix-tree: radix_tree_delete_item() Johannes Weiner 2013-08-06 22:44 ` Johannes Weiner 2013-08-06 22:44 ` [patch 2/9] mm: shmem: save one radix tree lookup when truncating swapped pages Johannes Weiner 2013-08-06 22:44 ` Johannes Weiner 2013-08-06 22:44 ` [patch 3/9] mm: filemap: move radix tree hole searching here Johannes Weiner 2013-08-06 22:44 ` Johannes Weiner 2013-08-06 22:44 ` [patch 4/9] mm + fs: prepare for non-page entries in page cache radix trees Johannes Weiner 2013-08-06 22:44 ` Johannes Weiner 2013-08-06 22:44 ` [patch 5/9] mm + fs: store shadow entries in page cache Johannes Weiner 2013-08-06 22:44 ` Johannes Weiner 2013-08-06 22:44 ` [patch 6/9] mm + fs: provide shadow pages to page cache allocations Johannes Weiner 2013-08-06 22:44 ` Johannes Weiner 2013-08-06 22:44 ` [patch 7/9] mm: make global_dirtyable_memory() available to other mm code Johannes Weiner 2013-08-06 22:44 ` Johannes Weiner 2013-08-06 22:44 ` [patch 8/9] mm: thrash detection-based file cache sizing Johannes Weiner 2013-08-06 22:44 ` Johannes Weiner 2013-08-09 22:49 ` Andrew Morton 2013-08-09 22:49 ` Andrew Morton 2013-08-12 16:00 ` Johannes Weiner 2013-08-12 16:00 ` Johannes Weiner 2013-08-11 21:57 ` Vlastimil Babka 2013-08-11 21:57 ` Vlastimil Babka 2013-08-12 16:27 ` Johannes Weiner [this message] 2013-08-12 16:27 ` Johannes Weiner 2013-08-06 22:44 ` [patch 9/9] mm: workingset: keep shadow entries in check Johannes Weiner 2013-08-06 22:44 ` Johannes Weiner 2013-08-11 23:56 ` Andi Kleen 2013-08-11 23:56 ` Andi Kleen 2013-08-14 14:41 ` Johannes Weiner 2013-08-14 14:41 ` Johannes Weiner 2013-08-09 22:53 ` [patch 0/9] mm: thrash detection-based file cache sizing v3 Andrew Morton 2013-08-09 22:53 ` Andrew Morton 2013-08-10 1:39 ` Ozgun Erdogan 2013-08-12 22:15 ` Johannes Weiner 2013-08-12 22:15 ` Johannes Weiner -- strict thread matches above, loose matches on Subject: below -- 2013-08-17 19:31 [patch 9/9] mm: thrash detection-based file cache sizing v4 Johannes Weiner 2013-08-17 19:31 ` [patch 8/9] mm: thrash detection-based file cache sizing Johannes Weiner 2013-08-17 19:31 ` Johannes Weiner 2013-08-20 20:59 ` Andrew Morton 2013-08-20 20:59 ` Andrew Morton 2013-08-22 8:45 ` Johannes Weiner 2013-08-22 8:45 ` Johannes Weiner 2013-08-06 22:22 [patch 0/9] mm: thrash detection-based file cache sizing v3 Johannes Weiner 2013-08-06 22:22 ` [patch 8/9] mm: thrash detection-based file cache sizing Johannes Weiner
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20130812162740.GS715@cmpxchg.org \ --to=hannes@cmpxchg.org \ --cc=aarcange@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=andi@firstfloor.org \ --cc=gthelen@google.com \ --cc=hch@infradead.org \ --cc=hughd@google.com \ --cc=jack@suse.cz \ --cc=klamm@yandex-team.ru \ --cc=kosaki.motohiro@jp.fujitsu.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=metin@citusdata.com \ --cc=mgorman@suse.de \ --cc=minchan.kim@gmail.com \ --cc=ozgun@citusdata.com \ --cc=peterz@infradead.org \ --cc=riel@redhat.com \ --cc=sjenning@linux.vnet.ibm.com \ --cc=vbabka@suse.cz \ --cc=walken@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.