All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tao Ma <tm@tao.ma>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	David Rientjes <rientjes@google.com>,
	Minchan Kim <minchan.kim@gmail.com>, Mel Gorman <mel@csn.ul.ie>,
	Johannes Weiner <jweiner@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] mm: do not drain pagevecs for mlock
Date: Fri, 30 Dec 2011 16:48:35 +0800	[thread overview]
Message-ID: <4EFD7AE3.8020403@tao.ma> (raw)
In-Reply-To: <CAHGf_=qOGy3MQgiFyfeG82+gbDXTBT5KQjgR7JqMfQ7e7RSGpA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

On 12/30/2011 04:11 PM, KOSAKI Motohiro wrote:
> 2011/12/30 Tao Ma <tm@tao.ma>:
>> In our test of mlock, we have found some severe performance regression
>> in it. Some more investigations show that mlocked is blocked heavily
>> by lur_add_drain_all which calls schedule_on_each_cpu and flush the work
>> queue which is very slower if we have several cpus.
>>
>> So we have tried 2 ways to solve it:
>> 1. Add a per cpu counter for all the pagevecs so that we don't schedule
>>   and flush the lru_drain work if the cpu doesn't have any pagevecs(I
>>   have finished the codes already).
>> 2. Remove the lru_add_drain_all.
>>
>> The first one has some problems since in our product system, all the cpus
>> are busy, so I guess there is very little chance for a cpu to have 0 pagevecs
>> except that you run several consecutive mlocks.
>>
>> From the commit log which added this function(8891d6da), it seems that we
>> don't have to call it. So the 2nd one seems to be both easy and workable and
>> comes this patch.
> 
> Could you please show us your system environment and benchmark programs?
> Usually lru_drain_** is very fast than mlock() body because it makes
> plenty memset(page).
The system environment is: 16 core Xeon E5620. 24G memory.

I have attached the program. It is very simple and just uses mlock/munlock.

Thanks
Tao

[-- Attachment #2: test_mlock.c --]
[-- Type: text/x-csrc, Size: 981 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <time.h>
#include <sys/time.h>
#include <sys/mman.h>

#define MM_SZ1 24
#define MM_SZ2 56
#define MM_SZ3 4168

void mlock_test()
{
	char ptr1[MM_SZ1];
	char ptr2[MM_SZ2];
	char ptr3[MM_SZ3];

	if(0 != mlock(ptr1, MM_SZ1) )
		perror("mlock MM_SZ1\n");
	if(0 != mlock(ptr2, MM_SZ2) )
		perror("mlock MM_SZ2\n");
	if(0 != mlock(ptr3, MM_SZ3) )
		perror("mlock MM_SZ3\n");

	if(0 != munlock(ptr1, MM_SZ1) )
		perror("munlock MM_SZ1\n");       
	if(0 != munlock(ptr2, MM_SZ2) )
		perror("munlock MM_SZ2\n");
	if(0 != munlock(ptr3, MM_SZ3) )
		perror("munlock MM_SZ3\n");
}

int main(int argc, char *argv[])
{
	int ret, opt;
	int i,cnt;

	while((opt = getopt(argc, argv, "c:")) != -1 )
	{
		switch(opt){
		case 'c':
			cnt = atoi(optarg);
			break;
		default:
			printf("Usage: %s [-c count] arg...\n", argv[0]);
			exit(EXIT_FAILURE);
		}
	}

	for(i = 0; i < cnt; i++)
		mlock_test();

	return 0;
}

  reply	other threads:[~2011-12-30  8:48 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-30  6:36 [PATCH] mm: do not drain pagevecs for mlock Tao Ma
2011-12-30  6:36 ` Tao Ma
2011-12-30  8:11 ` KOSAKI Motohiro
2011-12-30  8:11   ` KOSAKI Motohiro
2011-12-30  8:48   ` Tao Ma [this message]
2011-12-30  9:31     ` KOSAKI Motohiro
2011-12-30  9:31       ` KOSAKI Motohiro
2011-12-30  9:45       ` Tao Ma
2011-12-30  9:45         ` Tao Ma
2011-12-30 10:07         ` KOSAKI Motohiro
2011-12-30 10:07           ` KOSAKI Motohiro
2012-01-01  7:30           ` [PATCH 1/2] mm,mlock: drain pagevecs asynchronously kosaki.motohiro
2012-01-01  7:30             ` kosaki.motohiro
2012-01-04  1:17             ` Minchan Kim
2012-01-04  1:17               ` Minchan Kim
2012-01-04  2:38               ` KOSAKI Motohiro
2012-01-04  2:38                 ` KOSAKI Motohiro
2012-01-10  8:53                 ` Tao Ma
2012-01-10  8:53                   ` Tao Ma
2012-01-04  2:56             ` Hugh Dickins
2012-01-04  2:56               ` Hugh Dickins
2012-01-04 22:05             ` Andrew Morton
2012-01-04 22:05               ` Andrew Morton
2012-01-04 23:33               ` KOSAKI Motohiro
2012-01-04 23:33                 ` KOSAKI Motohiro
2012-01-05  0:19                 ` Hugh Dickins
2012-01-05  0:19                   ` Hugh Dickins
2012-01-01  7:30           ` [PATCH 2/2] sysvshm: SHM_LOCK use lru_add_drain_all_async() kosaki.motohiro
2012-01-01  7:30             ` kosaki.motohiro
2012-01-04  1:51             ` Hugh Dickins
2012-01-04  1:51               ` Hugh Dickins
2012-01-04  2:19               ` KOSAKI Motohiro
2012-01-04  2:19                 ` KOSAKI Motohiro
2012-01-04  5:17                 ` Hugh Dickins
2012-01-04  5:17                   ` Hugh Dickins
2012-01-04  8:34                   ` KOSAKI Motohiro
2012-01-04  8:34                     ` KOSAKI Motohiro
2012-01-06  6:13           ` [PATCH] mm: do not drain pagevecs for mlock Tao Ma
2012-01-06  6:13             ` Tao Ma
2012-01-06  6:18             ` KOSAKI Motohiro
2012-01-06  6:18               ` KOSAKI Motohiro
2012-01-06  6:30               ` Tao Ma
2012-01-06  6:30                 ` Tao Ma
2012-01-06  6:33                 ` KOSAKI Motohiro
2012-01-06  6:33                   ` KOSAKI Motohiro
2012-01-06  6:46                   ` Tao Ma
2012-01-06  6:46                     ` Tao Ma
2012-01-09 23:58                     ` KOSAKI Motohiro
2012-01-09 23:58                       ` KOSAKI Motohiro
2012-01-10  2:08                       ` Tao Ma
2012-01-10  2:08                         ` Tao Ma
2012-01-09  7:25           ` Tao Ma
2012-01-09  7:25             ` Tao Ma
2011-12-30 10:14         ` KOSAKI Motohiro
2011-12-30 10:14           ` KOSAKI Motohiro

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=4EFD7AE3.8020403@tao.ma \
    --to=tm@tao.ma \
    --cc=akpm@linux-foundation.org \
    --cc=jweiner@redhat.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=minchan.kim@gmail.com \
    --cc=rientjes@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: 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.