From: Darren Hart <dvhart@linux.intel.com>
To: zhang.yi20@zte.com.cn
Cc: Dave Hansen <dave@sr71.net>,
Dave Hansen <dave@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] futex: bugfix for futex-key conflict when futex use hugepage
Date: Thu, 18 Apr 2013 19:42:51 -0700 [thread overview]
Message-ID: <5170AF2B.80600@linux.intel.com> (raw)
In-Reply-To: <OFD8FA3C9D.ACFCFB28-ON48257B52.0008A691-48257B52.000C4DFB@zte.com.cn>
On 04/18/2013 07:13 PM, zhang.yi20@zte.com.cn wrote:
> Darren Hart <dvhart@linux.intel.com> wrote on 2013/04/18 22:34:29:
>
>> On 04/18/2013 01:05 AM, zhang.yi20@zte.com.cn wrote:
>>>
>>> I have run futextest/performance/futex_wait for testing,
>>> 5 times before make it long:
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 10215 Kiter/s
>>>
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 9862 Kiter/s
>>>
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 10081 Kiter/s
>>>
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 10060 Kiter/s
>>>
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 10081 Kiter/s
>>>
>>>
>>> And 5 times after make it long:
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 9940 Kiter/s
>>>
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 10204 Kiter/s
>>>
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 9901 Kiter/s
>>>
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 10152 Kiter/s
>>>
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 10060 Kiter/s
>>>
>>>
>>> Seems OK, is it?
>>>
>>
>> Changes appear to be in the noise, no impact with this load
>> anyway.
>> How many CPUs on your test machine? I presume not 256?
>>
>> --
>
> There are 16 CPUsGBP! and mode is:
> Intel(R) Xeon(R) CPU C5528 @ 2.13GHz
>
> Shall I make the number of threads as the CPUS? I test again with argument
> '-n 16', the result is similar.
No, I just wanted to be sure you weren't running 256 threads on 1 CPU as
you wouldn't be likely to be stressing the bucket list much :-)
> BTW, have you seen the testcase in my other mail? It seems to be rejected
> by LKML.
Might have something to do with what appears to still be HTML email. You
really need to fix your email client.
See: http://www.tux.org/lkml/
#12 in particular.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
--
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: Darren Hart <dvhart@linux.intel.com>
To: zhang.yi20@zte.com.cn
Cc: Dave Hansen <dave@sr71.net>,
Dave Hansen <dave@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] futex: bugfix for futex-key conflict when futex use hugepage
Date: Thu, 18 Apr 2013 19:42:51 -0700 [thread overview]
Message-ID: <5170AF2B.80600@linux.intel.com> (raw)
In-Reply-To: <OFD8FA3C9D.ACFCFB28-ON48257B52.0008A691-48257B52.000C4DFB@zte.com.cn>
On 04/18/2013 07:13 PM, zhang.yi20@zte.com.cn wrote:
> Darren Hart <dvhart@linux.intel.com> wrote on 2013/04/18 22:34:29:
>
>> On 04/18/2013 01:05 AM, zhang.yi20@zte.com.cn wrote:
>>>
>>> I have run futextest/performance/futex_wait for testing,
>>> 5 times before make it long:
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 10215 Kiter/s
>>>
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 9862 Kiter/s
>>>
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 10081 Kiter/s
>>>
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 10060 Kiter/s
>>>
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 10081 Kiter/s
>>>
>>>
>>> And 5 times after make it long:
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 9940 Kiter/s
>>>
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 10204 Kiter/s
>>>
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 9901 Kiter/s
>>>
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 10152 Kiter/s
>>>
>>> futex_wait: Measure FUTEX_WAIT operations per second
>>> Arguments: iterations=100000000 threads=256
>>> Result: 10060 Kiter/s
>>>
>>>
>>> Seems OK, is it?
>>>
>>
>> Changes appear to be in the noise, no impact with this load
>> anyway.
>> How many CPUs on your test machine? I presume not 256?
>>
>> --
>
> There are 16 CPUs, and mode is:
> Intel(R) Xeon(R) CPU C5528 @ 2.13GHz
>
> Shall I make the number of threads as the CPUS? I test again with argument
> '-n 16', the result is similar.
No, I just wanted to be sure you weren't running 256 threads on 1 CPU as
you wouldn't be likely to be stressing the bucket list much :-)
> BTW, have you seen the testcase in my other mail? It seems to be rejected
> by LKML.
Might have something to do with what appears to still be HTML email. You
really need to fix your email client.
See: http://www.tux.org/lkml/
#12 in particular.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
next prev parent reply other threads:[~2013-04-19 2:43 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-16 3:37 [PATCH] futex: bugfix for futex-key conflict when futex use hugepage zhang.yi20
2013-04-16 3:37 ` zhang.yi20
2013-04-16 17:57 ` Darren Hart
2013-04-16 17:57 ` Darren Hart
2013-04-17 9:55 ` zhang.yi20
2013-04-17 9:55 ` zhang.yi20
2013-04-17 14:18 ` Darren Hart
2013-04-17 14:18 ` Darren Hart
2013-04-17 15:26 ` Dave Hansen
2013-04-17 15:26 ` Dave Hansen
2013-04-17 15:51 ` Darren Hart
2013-04-17 15:51 ` Darren Hart
2013-04-18 8:05 ` zhang.yi20
2013-04-18 8:05 ` zhang.yi20
2013-04-18 14:34 ` Darren Hart
2013-04-18 14:34 ` Darren Hart
2013-04-19 2:13 ` zhang.yi20
2013-04-19 2:13 ` zhang.yi20
2013-04-19 2:42 ` Darren Hart [this message]
2013-04-19 2:42 ` Darren Hart
2013-04-19 2:45 ` Darren Hart
2013-04-19 2:45 ` Darren Hart
2013-04-19 7:03 ` zhang.yi20
2013-04-19 7:03 ` zhang.yi20
2013-04-18 10:14 ` 答复: " zhang.yi20
2013-04-16 18:37 ` Dave Hansen
2013-04-16 18:37 ` Dave Hansen
2013-04-16 18:47 ` Darren Hart
2013-04-16 18:47 ` Darren Hart
2013-04-17 7:25 ` 答复: " zhang.yi20
2013-04-17 7:47 ` zhang.yi20
2013-04-17 7:47 ` zhang.yi20
-- strict thread matches above, loose matches on Subject: below --
2013-05-15 13:57 Zhang Yi
2013-05-15 14:20 ` Mel Gorman
2013-05-16 1:16 ` zhang.yi20
2013-05-16 1:30 ` Darren Hart
2013-05-07 12:43 Zhang Yi
2013-04-26 12:13 Zhang Yi
2013-04-26 18:26 ` Thomas Gleixner
2013-05-07 12:23 ` Zhang Yi
2013-05-07 15:20 ` Mel Gorman
2013-05-07 15:24 ` Thomas Gleixner
2013-05-07 15:54 ` Mel Gorman
2013-05-07 12:34 ` Zhang Yi
2013-04-24 14:27 Zhang Yi
2013-04-24 13:58 Zhang Yi
2013-04-25 20:52 ` Thomas Gleixner
2013-04-08 6:34 jiang.biao2
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=5170AF2B.80600@linux.intel.com \
--to=dvhart@linux.intel.com \
--cc=dave@linux.vnet.ibm.com \
--cc=dave@sr71.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=zhang.yi20@zte.com.cn \
/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.