From: Vlastimil Babka <vbabka@suse.cz>
To: Mel Gorman <mgorman@techsingularity.net>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Linux-MM <linux-mm@kvack.org>,
Linux-FSDevel <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>, Jan Kara <jack@suse.cz>,
Andi Kleen <ak@linux.intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH 1/8] mm, page_alloc: Enable/disable IRQs once when freeing a list of pages
Date: Wed, 18 Oct 2017 11:02:18 +0200 [thread overview]
Message-ID: <bcd95a87-3f63-9f5d-77a0-2b2115f53919@suse.cz> (raw)
In-Reply-To: <20171018075952.10627-2-mgorman@techsingularity.net>
On 10/18/2017 09:59 AM, Mel Gorman wrote:
> Freeing a list of pages current enables/disables IRQs for each page freed.
> This patch splits freeing a list of pages into two operations -- preparing
> the pages for freeing and the actual freeing. This is a tradeoff - we're
> taking two passes of the list to free in exchange for avoiding multiple
> enable/disable of IRQs.
There's also some overhead of storing pfn in page->private, but all that
seems negligible compared to irq disable/enable...
> sparsetruncate (tiny)
> 4.14.0-rc4 4.14.0-rc4
> janbatch-v1r1 oneirq-v1r1
> Min Time 149.00 ( 0.00%) 141.00 ( 5.37%)
> 1st-qrtle Time 150.00 ( 0.00%) 142.00 ( 5.33%)
> 2nd-qrtle Time 151.00 ( 0.00%) 142.00 ( 5.96%)
> 3rd-qrtle Time 151.00 ( 0.00%) 143.00 ( 5.30%)
> Max-90% Time 153.00 ( 0.00%) 144.00 ( 5.88%)
> Max-95% Time 155.00 ( 0.00%) 147.00 ( 5.16%)
> Max-99% Time 201.00 ( 0.00%) 195.00 ( 2.99%)
> Max Time 236.00 ( 0.00%) 230.00 ( 2.54%)
> Amean Time 152.65 ( 0.00%) 144.37 ( 5.43%)
> Stddev Time 9.78 ( 0.00%) 10.44 ( -6.72%)
> Coeff Time 6.41 ( 0.00%) 7.23 ( -12.84%)
> Best99%Amean Time 152.07 ( 0.00%) 143.72 ( 5.50%)
> Best95%Amean Time 150.75 ( 0.00%) 142.37 ( 5.56%)
> Best90%Amean Time 150.59 ( 0.00%) 142.19 ( 5.58%)
> Best75%Amean Time 150.36 ( 0.00%) 141.92 ( 5.61%)
> Best50%Amean Time 150.04 ( 0.00%) 141.69 ( 5.56%)
> Best25%Amean Time 149.85 ( 0.00%) 141.38 ( 5.65%)
>
> With a tiny number of files, each file truncated has resident page cache
> and it shows that time to truncate is roughtly 5-6% with some minor jitter.
>
> 4.14.0-rc4 4.14.0-rc4
> janbatch-v1r1 oneirq-v1r1
> Hmean SeqCreate ops 65.27 ( 0.00%) 81.86 ( 25.43%)
> Hmean SeqCreate read 39.48 ( 0.00%) 47.44 ( 20.16%)
> Hmean SeqCreate del 24963.95 ( 0.00%) 26319.99 ( 5.43%)
> Hmean RandCreate ops 65.47 ( 0.00%) 82.01 ( 25.26%)
> Hmean RandCreate read 42.04 ( 0.00%) 51.75 ( 23.09%)
> Hmean RandCreate del 23377.66 ( 0.00%) 23764.79 ( 1.66%)
>
> As expected, there is a small gain for the delete operation.
Looks good.
> Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
A nit below.
> @@ -2647,11 +2663,25 @@ void free_hot_cold_page(struct page *page, bool cold)
> void free_hot_cold_page_list(struct list_head *list, bool cold)
> {
> struct page *page, *next;
> + unsigned long flags, pfn;
> +
> + /* Prepare pages for freeing */
> + list_for_each_entry_safe(page, next, list, lru) {
> + pfn = page_to_pfn(page);
> + if (!free_hot_cold_page_prepare(page, pfn))
> + list_del(&page->lru);
> + page->private = pfn;
We have (set_)page_private() helpers so better to use them (makes it a
bit easier to check for all places where page->private is used to e.g.
avoid a clash)?
> + }
>
> + local_irq_save(flags);
> list_for_each_entry_safe(page, next, list, lru) {
> + unsigned long pfn = page->private;
> +
> + page->private = 0;
Same here.
> trace_mm_page_free_batched(page, cold);
> - free_hot_cold_page(page, cold);
> + free_hot_cold_page_commit(page, pfn, cold);
> }
> + local_irq_restore(flags);
> }
>
> /*
>
next prev parent reply other threads:[~2017-10-18 9:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-18 7:59 [PATCH 0/8] Follow-up for speed up page cache truncation v2 Mel Gorman
2017-10-18 7:59 ` [PATCH 1/8] mm, page_alloc: Enable/disable IRQs once when freeing a list of pages Mel Gorman
2017-10-18 9:02 ` Vlastimil Babka [this message]
2017-10-18 10:15 ` Mel Gorman
2017-10-18 7:59 ` [PATCH 2/8] mm, truncate: Do not check mapping for every page being truncated Mel Gorman
2017-10-19 8:11 ` Jan Kara
2017-10-18 7:59 ` [PATCH 3/8] mm, truncate: Remove all exceptional entries from pagevec under one lock Mel Gorman
2017-10-18 7:59 ` [PATCH 4/8] mm: Only drain per-cpu pagevecs once per pagevec usage Mel Gorman
2017-10-19 9:12 ` Vlastimil Babka
2017-10-19 9:33 ` Mel Gorman
2017-10-19 13:21 ` Vlastimil Babka
2017-10-18 7:59 ` [PATCH 5/8] mm, pagevec: Remove cold parameter for pagevecs Mel Gorman
2017-10-19 9:24 ` Vlastimil Babka
2017-10-18 7:59 ` [PATCH 6/8] mm: Remove cold parameter for release_pages Mel Gorman
2017-10-19 9:26 ` Vlastimil Babka
2017-10-18 7:59 ` [PATCH 7/8] mm, Remove cold parameter from free_hot_cold_page* Mel Gorman
2017-10-19 13:12 ` Vlastimil Babka
2017-10-19 15:43 ` Mel Gorman
2017-10-18 7:59 ` [PATCH 8/8] mm: Remove __GFP_COLD Mel Gorman
2017-10-19 13:18 ` Vlastimil Babka
2017-10-19 13:42 ` Vlastimil Babka
2017-10-19 14:32 ` Mel Gorman
-- strict thread matches above, loose matches on Subject: below --
2017-10-12 9:30 [PATCH 0/8] Follow-up for speed up page cache truncation Mel Gorman
2017-10-12 9:30 ` [PATCH 1/8] mm, page_alloc: Enable/disable IRQs once when freeing a list of pages Mel Gorman
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=bcd95a87-3f63-9f5d-77a0-2b2115f53919@suse.cz \
--to=vbabka@suse.cz \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).