All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@linux.vnet.ibm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Pavel Emelyanov <xemul@virtuozzo.com>,
	linux-mm <linux-mm@kvack.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE
Date: Thu, 1 Jun 2017 09:53:02 +0300	[thread overview]
Message-ID: <20170601065302.GA30495@rapoport-lnx> (raw)
In-Reply-To: <20170530143941.GK7969@dhcp22.suse.cz>

On Tue, May 30, 2017 at 04:39:41PM +0200, Michal Hocko wrote:
> On Tue 30-05-17 16:04:56, Andrea Arcangeli wrote:
> > 
> > UFFDIO_COPY while not being a major slowdown for sure, it's likely
> > measurable at the microbenchmark level because it would add a
> > enter/exit kernel to every 4k memcpy. It's not hard to imagine that as
> > measurable. How that impacts the total precopy time I don't know, it
> > would need to be benchmarked to be sure.
> 
> Yes, please!

I've run a simple test (below) that fills 1G of memory either with memcpy
of ioctl(UFFDIO_COPY) in 4K chunks.
The machine I used has two "Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz" and
128G of RAM.
I've averaged elapsed time reported by /usr/bin/time over 100 runs and here
what I've got:

memcpy with THP on: 0.3278 sec
memcpy with THP off: 0.5295 sec
UFFDIO_COPY: 0.44 sec

That said, for the CRIU usecase UFFDIO_COPY seems faster that disabling THP
and then doing memcpy.

--
Sincerely yours,
Mike.

----------------------------------------------------------
{
	...

	src = mmap(NULL, page_size, PROT_READ | PROT_WRITE,
		   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
	if (src == MAP_FAILED)
		fprintf(stderr, "map src failed\n"), exit(1);
	*((unsigned long *)src) = 1;

 	if (disable_huge && prctl(PR_SET_THP_DISABLE, 1, 0, 0, 0))
		fprintf(stderr, "ptctl failed\n"), exit(1);

	dst = mmap(NULL, page_size * nr_pages, PROT_READ | PROT_WRITE,
		   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
	if (dst == MAP_FAILED)
		fprintf(stderr, "map dst failed\n"), exit(1);

	if (use_uffd && userfaultfd_register(dst))
		fprintf(stderr, "userfault_register failed\n"), exit(1);

	for (i = 0; i < nr_pages; i++) {
		char *address = dst + i * page_size;

		if (use_uffd) {
			struct uffdio_copy uffdio_copy;

			uffdio_copy.dst = (unsigned long)address;
			uffdio_copy.src = (unsigned long)src;
			uffdio_copy.len = page_size;
			uffdio_copy.mode = 0;
			uffdio_copy.copy = 0;

			ret = ioctl(uffd, UFFDIO_COPY, &uffdio_copy);
			if (ret)
				fprintf(stderr, "copy: %d, %d\n", ret, errno),
					exit(1);
		} else {
			memcpy(address, src, page_size);
		}

	}

	return 0;
}

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

WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.vnet.ibm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Pavel Emelyanov <xemul@virtuozzo.com>,
	linux-mm <linux-mm@kvack.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE
Date: Thu, 1 Jun 2017 09:53:02 +0300	[thread overview]
Message-ID: <20170601065302.GA30495@rapoport-lnx> (raw)
In-Reply-To: <20170530143941.GK7969@dhcp22.suse.cz>

On Tue, May 30, 2017 at 04:39:41PM +0200, Michal Hocko wrote:
> On Tue 30-05-17 16:04:56, Andrea Arcangeli wrote:
> > 
> > UFFDIO_COPY while not being a major slowdown for sure, it's likely
> > measurable at the microbenchmark level because it would add a
> > enter/exit kernel to every 4k memcpy. It's not hard to imagine that as
> > measurable. How that impacts the total precopy time I don't know, it
> > would need to be benchmarked to be sure.
> 
> Yes, please!

I've run a simple test (below) that fills 1G of memory either with memcpy
of ioctl(UFFDIO_COPY) in 4K chunks.
The machine I used has two "Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz" and
128G of RAM.
I've averaged elapsed time reported by /usr/bin/time over 100 runs and here
what I've got:

memcpy with THP on: 0.3278 sec
memcpy with THP off: 0.5295 sec
UFFDIO_COPY: 0.44 sec

That said, for the CRIU usecase UFFDIO_COPY seems faster that disabling THP
and then doing memcpy.

--
Sincerely yours,
Mike.

----------------------------------------------------------
{
	...

	src = mmap(NULL, page_size, PROT_READ | PROT_WRITE,
		   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
	if (src == MAP_FAILED)
		fprintf(stderr, "map src failed\n"), exit(1);
	*((unsigned long *)src) = 1;

 	if (disable_huge && prctl(PR_SET_THP_DISABLE, 1, 0, 0, 0))
		fprintf(stderr, "ptctl failed\n"), exit(1);

	dst = mmap(NULL, page_size * nr_pages, PROT_READ | PROT_WRITE,
		   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
	if (dst == MAP_FAILED)
		fprintf(stderr, "map dst failed\n"), exit(1);

	if (use_uffd && userfaultfd_register(dst))
		fprintf(stderr, "userfault_register failed\n"), exit(1);

	for (i = 0; i < nr_pages; i++) {
		char *address = dst + i * page_size;

		if (use_uffd) {
			struct uffdio_copy uffdio_copy;

			uffdio_copy.dst = (unsigned long)address;
			uffdio_copy.src = (unsigned long)src;
			uffdio_copy.len = page_size;
			uffdio_copy.mode = 0;
			uffdio_copy.copy = 0;

			ret = ioctl(uffd, UFFDIO_COPY, &uffdio_copy);
			if (ret)
				fprintf(stderr, "copy: %d, %d\n", ret, errno),
					exit(1);
		} else {
			memcpy(address, src, page_size);
		}

	}

	return 0;
}

  parent reply	other threads:[~2017-06-01  6:53 UTC|newest]

Thread overview: 117+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-22  6:12 [PATCH] mm: introduce MADV_CLR_HUGEPAGE Mike Rapoport
2017-05-22  6:12 ` Mike Rapoport
2017-05-22  7:26 ` Anshuman Khandual
2017-05-22  7:26   ` Anshuman Khandual
2017-05-22  8:12   ` Mike Rapoport
2017-05-22  8:12     ` Mike Rapoport
2017-05-22 11:42 ` Kirill A. Shutemov
2017-05-22 11:42   ` Kirill A. Shutemov
2017-05-22 13:36   ` Mike Rapoport
2017-05-22 13:36     ` Mike Rapoport
2017-05-22 13:44     ` Kirill A. Shutemov
2017-05-22 13:44       ` Kirill A. Shutemov
2017-05-22 13:55     ` Michal Hocko
2017-05-22 13:55       ` Michal Hocko
2017-05-22 14:29       ` Mike Rapoport
2017-05-22 14:29         ` Mike Rapoport
2017-05-22 15:52         ` Vlastimil Babka
2017-05-22 15:52           ` Vlastimil Babka
2017-05-22 17:51           ` Mike Rapoport
2017-05-22 17:51             ` Mike Rapoport
2017-05-24  7:50           ` Mike Rapoport
2017-05-24  7:50             ` Mike Rapoport
2017-05-24  7:58             ` Vlastimil Babka
2017-05-24  7:58               ` Vlastimil Babka
2017-05-24  7:58               ` Vlastimil Babka
2017-05-24 10:39               ` Mike Rapoport
2017-05-24 10:39                 ` Mike Rapoport
2017-05-24 11:18                 ` Michal Hocko
2017-05-24 11:18                   ` Michal Hocko
2017-05-24 14:25                   ` Pavel Emelyanov
2017-05-24 14:25                     ` Pavel Emelyanov
2017-05-24 14:27                   ` Mike Rapoport
2017-05-24 14:27                     ` Mike Rapoport
2017-05-24 15:22                     ` Andrea Arcangeli
2017-05-24 15:22                       ` Andrea Arcangeli
2017-05-30  7:44                     ` Michal Hocko
2017-05-30  7:44                       ` Michal Hocko
2017-05-30  7:44                       ` Michal Hocko
     [not found]                       ` <20170530074408.GA7969-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-30 10:19                         ` Mike Rapoport
2017-05-30 10:19                           ` Mike Rapoport
2017-05-30 10:19                           ` Mike Rapoport
2017-05-30 10:39                           ` Michal Hocko
2017-05-30 10:39                             ` Michal Hocko
     [not found]                             ` <20170530103930.GB7969-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-30 14:04                               ` Andrea Arcangeli
2017-05-30 14:04                                 ` Andrea Arcangeli
2017-05-30 14:04                                 ` Andrea Arcangeli
2017-05-30 14:39                                 ` Michal Hocko
2017-05-30 14:39                                   ` Michal Hocko
     [not found]                                   ` <20170530143941.GK7969-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-30 14:56                                     ` Michal Hocko
2017-05-30 14:56                                       ` Michal Hocko
2017-05-30 14:56                                       ` Michal Hocko
     [not found]                                       ` <20170530145632.GL7969-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-30 16:06                                         ` Andrea Arcangeli
2017-05-30 16:06                                           ` Andrea Arcangeli
2017-05-30 16:06                                           ` Andrea Arcangeli
2017-05-31  6:30                                           ` Vlastimil Babka
2017-05-31  6:30                                             ` Vlastimil Babka
2017-05-31  8:24                                             ` Michal Hocko
2017-05-31  8:24                                               ` Michal Hocko
2017-05-31  9:27                                               ` Mike Rapoport
2017-05-31  9:27                                                 ` Mike Rapoport
2017-05-31 10:24                                                 ` Michal Hocko
2017-05-31 10:24                                                   ` Michal Hocko
     [not found]                                               ` <20170531082414.GB27783-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-31 10:22                                                 ` Michal Hocko
2017-05-31 10:22                                                   ` Michal Hocko
2017-05-31 10:22                                                   ` Michal Hocko
2017-06-01 11:00                                               ` Mike Rapoport
2017-06-01 11:00                                                 ` Mike Rapoport
2017-06-01 12:27                                                 ` Michal Hocko
2017-06-01 12:27                                                   ` Michal Hocko
2017-05-30 15:43                                   ` Andrea Arcangeli
2017-05-30 15:43                                     ` Andrea Arcangeli
2017-05-31 12:08                                     ` Michal Hocko
2017-05-31 12:08                                       ` Michal Hocko
     [not found]                                       ` <20170531120822.GL27783-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-31 12:39                                         ` Mike Rapoprt
2017-05-31 12:39                                           ` Mike Rapoprt
2017-05-31 12:39                                           ` Mike Rapoprt
2017-05-31 14:18                                           ` Andrea Arcangeli
2017-05-31 14:18                                             ` Andrea Arcangeli
     [not found]                                             ` <20170531141809.GB302-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-05-31 14:32                                               ` Michal Hocko
2017-05-31 14:32                                                 ` Michal Hocko
2017-05-31 14:32                                                 ` Michal Hocko
2017-05-31 15:46                                                 ` Andrea Arcangeli
2017-05-31 15:46                                                   ` Andrea Arcangeli
2017-06-01  6:58                                               ` Mike Rapoport
2017-06-01  6:58                                                 ` Mike Rapoport
2017-06-01  6:58                                                 ` Mike Rapoport
     [not found]                                           ` <8FA5E4C2-D289-4AF5-AA09-6C199E58F9A5-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-05-31 14:19                                             ` Michal Hocko
2017-05-31 14:19                                               ` Michal Hocko
2017-05-31 14:19                                               ` Michal Hocko
2017-06-01  6:53                                   ` Mike Rapoport [this message]
2017-06-01  6:53                                     ` Mike Rapoport
2017-06-01  8:09                                     ` Michal Hocko
2017-06-01  8:09                                       ` Michal Hocko
     [not found]                                       ` <20170601080909.GD32677-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-06-01  8:35                                         ` Mike Rapoport
2017-06-01  8:35                                           ` Mike Rapoport
2017-06-01  8:35                                           ` Mike Rapoport
2017-06-01 13:45                                       ` Andrea Arcangeli
2017-06-01 13:45                                         ` Andrea Arcangeli
2017-06-02  9:11                                         ` Mike Rapoport
2017-06-02  9:11                                           ` Mike Rapoport
2017-05-31  9:08                               ` Mike Rapoport
2017-05-31  9:08                                 ` Mike Rapoport
2017-05-31  9:08                                 ` Mike Rapoport
2017-05-31 12:05                                 ` Michal Hocko
2017-05-31 12:05                                   ` Michal Hocko
2017-05-31 12:25                                   ` Mike Rapoprt
2017-05-31 12:25                                     ` Mike Rapoprt
2017-05-24 11:31                 ` Vlastimil Babka
2017-05-24 11:31                   ` Vlastimil Babka
2017-05-24 14:28                   ` Pavel Emelyanov
2017-05-24 14:28                     ` Pavel Emelyanov
2017-05-24 14:54                     ` Vlastimil Babka
2017-05-24 14:54                       ` Vlastimil Babka
2017-05-24 15:13                       ` Mike Rapoport
2017-05-24 15:13                         ` Mike Rapoport
2017-05-22 15:33 ` kbuild test robot
2017-05-22 15:33   ` kbuild test robot

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=20170601065302.GA30495@rapoport-lnx \
    --to=rppt@linux.vnet.ibm.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=vbabka@suse.cz \
    --cc=xemul@virtuozzo.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: 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.