All of lore.kernel.org
 help / color / mirror / Atom feed
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);
>  }
>  
>  /*
> 

WARNING: multiple messages have this Message-ID (diff)
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);
>  }
>  
>  /*
> 

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

  reply	other threads:[~2017-10-18  9:04 UTC|newest]

Thread overview: 47+ 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 ` 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  7:59   ` Mel Gorman
2017-10-18  9:02   ` Vlastimil Babka [this message]
2017-10-18  9:02     ` Vlastimil Babka
2017-10-18 10:15     ` Mel Gorman
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-18  7:59   ` Mel Gorman
2017-10-19  8:11   ` Jan Kara
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   ` Mel Gorman
2017-10-18  7:59 ` [PATCH 4/8] mm: Only drain per-cpu pagevecs once per pagevec usage Mel Gorman
2017-10-18  7:59   ` Mel Gorman
2017-10-19  9:12   ` Vlastimil Babka
2017-10-19  9:12     ` Vlastimil Babka
2017-10-19  9:33     ` Mel Gorman
2017-10-19  9:33       ` Mel Gorman
2017-10-19 13:21       ` Vlastimil Babka
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-18  7:59   ` Mel Gorman
2017-10-19  9:24   ` Vlastimil Babka
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-18  7:59   ` Mel Gorman
2017-10-19  9:26   ` Vlastimil Babka
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-18  7:59   ` Mel Gorman
2017-10-19 13:12   ` Vlastimil Babka
2017-10-19 13:12     ` Vlastimil Babka
2017-10-19 15:43     ` Mel Gorman
2017-10-19 15:43       ` Mel Gorman
2017-10-18  7:59 ` [PATCH 8/8] mm: Remove __GFP_COLD Mel Gorman
2017-10-18  7:59   ` Mel Gorman
2017-10-19 13:18   ` Vlastimil Babka
2017-10-19 13:18     ` Vlastimil Babka
2017-10-19 13:42   ` Vlastimil Babka
2017-10-19 13:42     ` Vlastimil Babka
2017-10-19 13:42     ` Vlastimil Babka
2017-10-19 14:32     ` Mel Gorman
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
2017-10-12  9:30   ` 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 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.