All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Török Edwin" <edwintorok@gmail.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Mike Waychison <mikew@google.com>, Ying Han <yinghan@google.com>,
	Ingo Molnar <mingo@elte.hu>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	akpm <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	Rohit Seth <rohitseth@google.com>,
	Hugh Dickins <hugh@veritas.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [RFC v1][PATCH]page_fault retry with NOPAGE_RETRY
Date: Sun, 30 Nov 2008 21:38:18 +0200	[thread overview]
Message-ID: <4932EBAA.60808@gmail.com> (raw)
In-Reply-To: <20081128121015.GC13786@wotan.suse.de>

On 2008-11-28 14:10, Nick Piggin wrote:
> This is what I have.
>
> It does two things. Firstly, it switches x86-64 over to use the xadd
> algorithm rather than the spinlock algorithm. This is actually significant
> in high contention situations, because the spinlock algorithm doesn't allow
> concurrent operations on the lock while the queue of waiters is being
> manipulated.
>
> Secondly, it moves wakeups out from underneath the waiter queue lock. This
> is more significant on bigger machines where wakeup latency is worse and/or
> runqueue locks are very heavily contended.
>
> Now both these changes are going to help *mainly* for the case when there are
> a significant number of readers and writers, I think. So your write-heavy
> workload may not win anything. I noticed some speedup a long time ago on
> some weird java (volanomark) workload.

Hi,

I just tested your patch on top of tip/master, and my testprogram has
segfaulted :(
It is either something wrong in tip/master or the patch, or my program.
This is the first time this testprogram segfaults, and it doesn't have a
reason to segfault there.


[  140.624155] scalability[4995]: segfault at 7f9ce137f000 ip
0000000000401a62 sp 00000000454950a0 error 4 in scalability[400000+3000]
[  401.640738] scalability[5398]: segfault at 7fdbffba3000 ip
0000000000401a62 sp 00000000423d70a0 error 4 in scalability[400000+3000]

Here is the relevant portion, at 401a62 I read from the mapping:

static void mmap_worker_fn(int fd, off_t len)
{
    char *data = mmap(NULL, len, PROT_READ, MAP_PRIVATE, fd, 0);
  401a4f:    48 89 c7                 mov    %rax,%rdi
    if(data == MAP_FAILED) {
  401a52:    74 36                    je     401a8a <mmap_worker_fn+0x5a>
        perror("mmap");
        abort();
  401a54:    31 d2                    xor    %edx,%edx
  401a56:    31 c9                    xor    %ecx,%ecx
static pthread_mutex_t thrtime_mtx = PTHREAD_MUTEX_INITIALIZER;

static size_t execute(const char *data, size_t len)
{
    size_t sum = 0, i;
    for(i=0;i<len;++i)
  401a58:    48 85 db                 test   %rbx,%rbx
  401a5b:    74 28                    je     401a85 <mmap_worker_fn+0x55>
  401a5d:    0f 1f 00                 nopl   (%rax)
        if(data[i] == 'd')
            ++sum;
  401a60:    31 c0                    xor    %eax,%eax
  401a62:    80 3c 17 64              cmpb   $0x64,(%rdi,%rdx,1)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This simply reads from the mapping

  401a66:    0f 94 c0                 sete   %al
static pthread_mutex_t thrtime_mtx = PTHREAD_MUTEX_INITIALIZER;

Steps to reproduce:
# sync; echo 3 >/proc/sys/vm/drop_caches; sync
# echo 0 >/proc/lock_stat
$ sudo ./scalability 16 /usr/bin/
... prints out results for read, and while running mmap_worker ...
... a message about segmentation fault ....

The testprogram is available here:
http://edwintorok.googlepages.com/tst.tar.gz

My .config:
http://edwintorok.googlepages.com/config

Can you reproduce the crash on your box?
Can I help debugging the problem?

Best regards,
--Edwin

WARNING: multiple messages have this Message-ID (diff)
From: "Török Edwin" <edwintorok@gmail.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Mike Waychison <mikew@google.com>, Ying Han <yinghan@google.com>,
	Ingo Molnar <mingo@elte.hu>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	akpm <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	Rohit Seth <rohitseth@google.com>,
	Hugh Dickins <hugh@veritas.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [RFC v1][PATCH]page_fault retry with NOPAGE_RETRY
Date: Sun, 30 Nov 2008 21:38:18 +0200	[thread overview]
Message-ID: <4932EBAA.60808@gmail.com> (raw)
In-Reply-To: <20081128121015.GC13786@wotan.suse.de>

On 2008-11-28 14:10, Nick Piggin wrote:
> This is what I have.
>
> It does two things. Firstly, it switches x86-64 over to use the xadd
> algorithm rather than the spinlock algorithm. This is actually significant
> in high contention situations, because the spinlock algorithm doesn't allow
> concurrent operations on the lock while the queue of waiters is being
> manipulated.
>
> Secondly, it moves wakeups out from underneath the waiter queue lock. This
> is more significant on bigger machines where wakeup latency is worse and/or
> runqueue locks are very heavily contended.
>
> Now both these changes are going to help *mainly* for the case when there are
> a significant number of readers and writers, I think. So your write-heavy
> workload may not win anything. I noticed some speedup a long time ago on
> some weird java (volanomark) workload.

Hi,

I just tested your patch on top of tip/master, and my testprogram has
segfaulted :(
It is either something wrong in tip/master or the patch, or my program.
This is the first time this testprogram segfaults, and it doesn't have a
reason to segfault there.


[  140.624155] scalability[4995]: segfault at 7f9ce137f000 ip
0000000000401a62 sp 00000000454950a0 error 4 in scalability[400000+3000]
[  401.640738] scalability[5398]: segfault at 7fdbffba3000 ip
0000000000401a62 sp 00000000423d70a0 error 4 in scalability[400000+3000]

Here is the relevant portion, at 401a62 I read from the mapping:

static void mmap_worker_fn(int fd, off_t len)
{
    char *data = mmap(NULL, len, PROT_READ, MAP_PRIVATE, fd, 0);
  401a4f:    48 89 c7                 mov    %rax,%rdi
    if(data == MAP_FAILED) {
  401a52:    74 36                    je     401a8a <mmap_worker_fn+0x5a>
        perror("mmap");
        abort();
  401a54:    31 d2                    xor    %edx,%edx
  401a56:    31 c9                    xor    %ecx,%ecx
static pthread_mutex_t thrtime_mtx = PTHREAD_MUTEX_INITIALIZER;

static size_t execute(const char *data, size_t len)
{
    size_t sum = 0, i;
    for(i=0;i<len;++i)
  401a58:    48 85 db                 test   %rbx,%rbx
  401a5b:    74 28                    je     401a85 <mmap_worker_fn+0x55>
  401a5d:    0f 1f 00                 nopl   (%rax)
        if(data[i] == 'd')
            ++sum;
  401a60:    31 c0                    xor    %eax,%eax
  401a62:    80 3c 17 64              cmpb   $0x64,(%rdi,%rdx,1)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This simply reads from the mapping

  401a66:    0f 94 c0                 sete   %al
static pthread_mutex_t thrtime_mtx = PTHREAD_MUTEX_INITIALIZER;

Steps to reproduce:
# sync; echo 3 >/proc/sys/vm/drop_caches; sync
# echo 0 >/proc/lock_stat
$ sudo ./scalability 16 /usr/bin/
... prints out results for read, and while running mmap_worker ...
... a message about segmentation fault ....

The testprogram is available here:
http://edwintorok.googlepages.com/tst.tar.gz

My .config:
http://edwintorok.googlepages.com/config

Can you reproduce the crash on your box?
Can I help debugging the problem?

Best regards,
--Edwin

--
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:[~2008-11-30 19:38 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-22  6:47 [RFC v1][PATCH]page_fault retry with NOPAGE_RETRY Ying Han
2008-11-22  6:47 ` Ying Han
2008-11-22  7:15 ` Andrew Morton
2008-11-22  7:15   ` Andrew Morton
2008-11-23  9:18 ` Ingo Molnar
2008-11-23  9:18   ` Ingo Molnar
2008-11-23 18:24   ` Andrew Morton
2008-11-23 18:24     ` Andrew Morton
2008-11-25 18:42   ` Ying Han
2008-11-25 18:42     ` Ying Han
2008-11-26 12:32     ` Nick Piggin
2008-11-26 12:32       ` Nick Piggin
2008-11-26 19:57       ` Mike Waychison
2008-11-26 19:57         ` Mike Waychison
2008-11-27  8:55         ` Nick Piggin
2008-11-27  8:55           ` Nick Piggin
2008-11-27  9:28           ` Mike Waychison
2008-11-27  9:28             ` Mike Waychison
2008-11-27 10:00             ` Peter Zijlstra
2008-11-27 10:00               ` Peter Zijlstra
2008-11-27 10:14               ` Nick Piggin
2008-11-27 10:14                 ` Nick Piggin
2008-11-27 19:22                 ` Mike Waychison
2008-11-27 19:22                   ` Mike Waychison
2008-11-28  9:41                   ` Nick Piggin
2008-11-28  9:41                     ` Nick Piggin
2008-11-28 22:46                     ` Mike Waychison
2008-11-28 22:46                       ` Mike Waychison
2008-11-27 11:08               ` KOSAKI Motohiro
2008-11-27 11:08                 ` KOSAKI Motohiro
2008-11-27 19:10               ` Mike Waychison
2008-11-27 19:10                 ` Mike Waychison
2008-11-27 11:39             ` Török Edwin
2008-11-27 11:39               ` Török Edwin
2008-11-27 12:03               ` Nick Piggin
2008-11-27 12:03                 ` Nick Piggin
2008-11-27 12:21                 ` Török Edwin
2008-11-27 12:21                   ` Török Edwin
2008-11-27 12:32                   ` Peter Zijlstra
2008-11-27 12:32                     ` Peter Zijlstra
2008-11-27 12:39                   ` Nick Piggin
2008-11-27 12:39                     ` Nick Piggin
2008-11-27 12:52                     ` Török Edwin
2008-11-27 12:52                       ` Török Edwin
2008-11-27 13:05                       ` Nick Piggin
2008-11-27 13:05                         ` Nick Piggin
2008-11-27 13:10                         ` Török Edwin
2008-11-27 13:10                           ` Török Edwin
2008-11-27 13:12                           ` Nick Piggin
2008-11-27 13:12                             ` Nick Piggin
2008-11-27 13:23                             ` Török Edwin
2008-11-27 13:23                               ` Török Edwin
2008-11-28 12:10                               ` Nick Piggin
2008-11-28 12:10                                 ` Nick Piggin
2008-11-30 19:38                                 ` Török Edwin [this message]
2008-11-30 19:38                                   ` Török Edwin
2008-12-01  8:52                                   ` Nick Piggin
2008-12-01  8:52                                     ` Nick Piggin
2008-12-01 11:13                                   ` Nick Piggin
2008-12-01 11:13                                     ` Nick Piggin
2008-12-01 11:37                                     ` Török Edwin
2008-12-01 11:37                                       ` Török Edwin
2008-12-04 22:27                       ` Ying Han
2008-12-04 22:27                         ` Ying Han
2008-12-05  6:50                         ` Török Edwin
2008-12-05  6:50                           ` Török Edwin
2008-11-27 13:08             ` Nick Piggin
2008-11-27 13:08               ` Nick Piggin
2008-11-27 19:03               ` Mike Waychison
2008-11-27 19:03                 ` Mike Waychison
2008-11-28  9:37                 ` Nick Piggin
2008-11-28  9:37                   ` Nick Piggin
2008-11-28 23:02                   ` Mike Waychison
2008-11-28 23:02                     ` Mike Waychison
2008-11-30 19:54                     ` Török Edwin
2008-11-30 19:54                       ` Török Edwin
2008-12-01  4:50                       ` Mike Waychison
2008-12-01  4:50                         ` Mike Waychison
2008-12-01  8:58                       ` Nick Piggin
2008-12-01  8:58                         ` Nick Piggin
2008-12-01 11:45                     ` Nick Piggin
2008-12-01 11:45                       ` Nick Piggin

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=4932EBAA.60808@gmail.com \
    --to=edwintorok@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mikew@google.com \
    --cc=mingo@elte.hu \
    --cc=npiggin@suse.de \
    --cc=rientjes@google.com \
    --cc=rohitseth@google.com \
    --cc=yinghan@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.