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>
next prev parent reply other threads:[~2008-11-30 19:38 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-22 6:47 Ying Han
2008-11-22 7:15 ` Andrew Morton
2008-11-23 9:18 ` Ingo Molnar
2008-11-23 18:24 ` Andrew Morton
2008-11-25 18:42 ` Ying Han
2008-11-26 12:32 ` Nick Piggin
2008-11-26 19:57 ` Mike Waychison
2008-11-27 8:55 ` Nick Piggin
2008-11-27 9:28 ` Mike Waychison
2008-11-27 10:00 ` Peter Zijlstra
2008-11-27 10:14 ` Nick Piggin
2008-11-27 19:22 ` Mike Waychison
2008-11-28 9:41 ` Nick Piggin
2008-11-28 22:46 ` Mike Waychison
2008-11-27 11:08 ` KOSAKI Motohiro
2008-11-27 19:10 ` Mike Waychison
2008-11-27 11:39 ` Török Edwin
2008-11-27 12:03 ` Nick Piggin
2008-11-27 12:21 ` Török Edwin
2008-11-27 12:32 ` Peter Zijlstra
2008-11-27 12:39 ` Nick Piggin
2008-11-27 12:52 ` Török Edwin
2008-11-27 13:05 ` Nick Piggin
2008-11-27 13:10 ` Török Edwin
2008-11-27 13:12 ` Nick Piggin
2008-11-27 13:23 ` Török Edwin
2008-11-28 12:10 ` Nick Piggin
2008-11-30 19:38 ` Török Edwin [this message]
2008-12-01 8:52 ` Nick Piggin
2008-12-01 11:13 ` Nick Piggin
2008-12-01 11:37 ` Török Edwin
2008-12-04 22:27 ` Ying Han
2008-12-05 6:50 ` Török Edwin
2008-11-27 13:08 ` Nick Piggin
2008-11-27 19:03 ` Mike Waychison
2008-11-28 9:37 ` Nick Piggin
2008-11-28 23:02 ` Mike Waychison
2008-11-30 19:54 ` Török Edwin
2008-12-01 4:50 ` Mike Waychison
2008-12-01 8:58 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox