linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Wang <00107082@163.com>
To: liam.howlett@oracle.com
Cc: akpm@linux-foundation.org, ankitag@nvidia.com,
	bagasdotme@gmail.com, chunn@nvidia.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	regressions@lists.linux.dev, surenb@google.com,
	willy@infradead.org
Subject: Re: [REGRESSION]: mmap performance regression starting with k-6.1
Date: Sun, 26 Nov 2023 15:18:54 +0800	[thread overview]
Message-ID: <20231126071854.19490-1-00107082@163.com> (raw)
In-Reply-To: <20231123143452.erzar3sqhg37hjxz@revolver>


> What this gains us is the ability to remove contention on the mmap lock
> during page faults.  If you were to test contention around that lock,
> you will see a slowdown until you reach v6.4, where per-vma locking
> started to show up.  More benchmarking will show different types of
> fault handling outside of the mmap lock until (I believe) 6.6, where
> most (or all?) types are supported.

I add memory access between mmap and munmap to the simple stress, and timeit.
Following are the numbers measuring total system time for 10,000,000 rounds, it is not very good for 6.7.0-rc2
(The delta column is just "page fault" - "no page fault", roughly the extra time
needed in kernel to deal with page fault, I guess.)

+-----------+------------+---------------+------------------------------------+
|           | page fault | no page fault | delta(kernel time for page fault?) |
+-----------+------------+---------------+------------------------------------+
|   6.0.0   |    64s     |      13s      |                51s                 |
|   6.1.0   |    104s    |      49s      |                55s                 |
| 6.7.0-rc2 |   ~210s    |      67s      |                143s                |
+-----------+------------+---------------+------------------------------------+

Maybe there is something here needed to be tracked.

My test code now is:

	#define MAXN 1024
	struct { void* addr; size_t n; } maps[MAXN];
	void accessit(char *addr, size_t n) {
		for (int i=0; i<n; i+=128) addr[i]=i;
	}
	int main() {
		int i, n, k, r;
		void *p;
		for (i=0; i<MAXN; i++) {
			n = 1024*((rand()%32)+1);
			p = mmap(NULL, n, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
			if (p == MAP_FAILED) {
				perror("fail to mmap");
				return -1;
			}
			maps[i].addr = p; 
			maps[i].n = n;

		}
		for (i=0; i<10000000; i++) {
			k = rand()%MAXN;
	#ifdef PAGE_FAULT
			accessit((char*)maps[k].addr, maps[k].n);
	#endif
			r = munmap(maps[k].addr, maps[k].n);
			if (r) {
				perror("fail to munmap");
				return -1;
			}
			n = 1024*((rand()%32)+1);
			p = mmap(NULL, n, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
			if (p == MAP_FAILED) {
				perror("fail to mmap");
				return -1;
			}
			maps[k].addr = p; 
			maps[k].n = n;
		}
		for (i=0; i<MAXN; i++) munmap(maps[i].addr, maps[i].n);
		return 0;
	}

Thanks
David Wang


  parent reply	other threads:[~2023-11-26  7:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-22 20:03 [REGRESSION]: mmap performance regression starting with k-6.1 Chun Ng
2023-11-23  1:18 ` Bagas Sanjaya
2023-11-23  3:06   ` Chun Ng
2023-11-23  5:01     ` Bagas Sanjaya
2023-11-23  5:07 ` Bagas Sanjaya
2023-11-23  8:29   ` David Wang
2023-11-23 14:34   ` Liam R. Howlett
2023-11-24  5:08     ` Linux regression tracking #update (Thorsten Leemhuis)
2023-11-26  7:18     ` David Wang [this message]
2023-11-26 13:47       ` Matthew Wilcox
2023-11-23 15:38   ` Matthew Wilcox
2023-11-24  0:15     ` Bagas Sanjaya
2023-11-24  1:04       ` Matthew Wilcox
2023-11-24 11:52         ` Greg KH
2023-11-24 15:06           ` Matthew Wilcox
2023-11-24 15:13             ` Greg KH
2023-11-24 15:29             ` Linux regression tracking (Thorsten Leemhuis)

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=20231126071854.19490-1-00107082@163.com \
    --to=00107082@163.com \
    --cc=akpm@linux-foundation.org \
    --cc=ankitag@nvidia.com \
    --cc=bagasdotme@gmail.com \
    --cc=chunn@nvidia.com \
    --cc=liam.howlett@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=regressions@lists.linux.dev \
    --cc=surenb@google.com \
    --cc=willy@infradead.org \
    /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).