On Mon, Oct 03, 2016 at 10:32:04AM +0800, Xin Long wrote:
> On Fri, Sep 30, 2016 at 3:05 PM, Aaron Lu wrote:
> > On 08/23/2016 05:44 AM, Marcelo Ricardo Leitner wrote:
> >> Em 19-08-2016 04:24, Aaron Lu escreveu:
> >>> On Fri, Aug 19, 2016 at 04:19:39AM -0300, Marcelo Ricardo Leitner wrote:
>
On Fri, Sep 30, 2016 at 3:05 PM, Aaron Lu wrote:
> On 08/23/2016 05:44 AM, Marcelo Ricardo Leitner wrote:
>> Em 19-08-2016 04:24, Aaron Lu escreveu:
>>> On Fri, Aug 19, 2016 at 04:19:39AM -0300, Marcelo Ricardo Leitner wrote:
Hi,
Em 19-08-2016 02:29, Aaron Lu escreveu:
...
On 08/23/2016 05:44 AM, Marcelo Ricardo Leitner wrote:
> Em 19-08-2016 04:24, Aaron Lu escreveu:
>> On Fri, Aug 19, 2016 at 04:19:39AM -0300, Marcelo Ricardo Leitner wrote:
>>> Hi,
>>>
>>> Em 19-08-2016 02:29, Aaron Lu escreveu:
>>> ...
It doesn't look insane and sctp_wait_for_sndbuf may actua
On 08/23/2016 05:44 AM, Marcelo Ricardo Leitner wrote:
> Em 19-08-2016 04:24, Aaron Lu escreveu:
>> On Fri, Aug 19, 2016 at 04:19:39AM -0300, Marcelo Ricardo Leitner wrote:
>>> Hi,
>>>
>>> Em 19-08-2016 02:29, Aaron Lu escreveu:
>>> ...
It doesn't look insane and sctp_wait_for_sndbuf may actua
Em 19-08-2016 04:24, Aaron Lu escreveu:
On Fri, Aug 19, 2016 at 04:19:39AM -0300, Marcelo Ricardo Leitner wrote:
Hi,
Em 19-08-2016 02:29, Aaron Lu escreveu:
...
It doesn't look insane and sctp_wait_for_sndbuf may actually have
something to do with a larger sctp_chunk I suppose?
The same perf
On Fri, Aug 19, 2016 at 04:19:39AM -0300, Marcelo Ricardo Leitner wrote:
> Hi,
>
> Em 19-08-2016 02:29, Aaron Lu escreveu:
> ...
> > It doesn't look insane and sctp_wait_for_sndbuf may actually have
> > something to do with a larger sctp_chunk I suppose?
> >
> > The same perf record doesn't captu
Hi,
Em 19-08-2016 02:29, Aaron Lu escreveu:
...
It doesn't look insane and sctp_wait_for_sndbuf may actually have
something to do with a larger sctp_chunk I suppose?
The same perf record doesn't capture any sample for the good commit,
which suggests the nerperf process doesn't sleep in sctp_wai
On Thu, Aug 18, 2016 at 08:45:42PM +0800, Xin Long wrote:
> >> Hi, Aaron
> >>
> >> 1)
> >> I talked with Marcelo about this one.
> >> He said it might be related with cacheline. the new field distroyed
> >> the prior cacheline. So on top of commit 826d253d57b1, pls only add
> >> + unsigned
>> Hi, Aaron
>>
>> 1)
>> I talked with Marcelo about this one.
>> He said it might be related with cacheline. the new field distroyed
>> the prior cacheline. So on top of commit 826d253d57b1, pls only add
>> + unsigned long prsctp_param;
>>
>> to the end of struct sctp_chunk, then try.
>
>
On Thu, Aug 18, 2016 at 02:06:50AM +0800, Xin Long wrote:
> >
> > It doesn't seem memory is an issue.
> >
> > The whole dump is about the same.
> > The MemFree and MemAvailable doesn't change much.
> >
> Hi, Aaron
>
> 1)
> I talked with Marcelo about this one.
> He said it might be related with ca
>
> It doesn't seem memory is an issue.
>
> The whole dump is about the same.
> The MemFree and MemAvailable doesn't change much.
>
Hi, Aaron
1)
I talked with Marcelo about this one.
He said it might be related with cacheline. the new field distroyed
the prior cacheline. So on top of commit 826d
On 08/17/2016 04:58 PM, Xin Long wrote:
>>
>> It doesn't change on my desktop Sandybridge.
>>
>> $ cat 4.7.0-rc6-01199-g116558d316e8/0/netperf.json
>> {
>> "netperf.Throughput_Mbps": [
>>748.205624998
>> ]
>> }
>>
>> Where commit 116558d316e8 is based on top of the last test commit
>> 9
>
> It doesn't change on my desktop Sandybridge.
>
> $ cat 4.7.0-rc6-01199-g116558d316e8/0/netperf.json
> {
> "netperf.Throughput_Mbps": [
>748.205624998
> ]
> }
>
> Where commit 116558d316e8 is based on top of the last test commit
> 98dd2532b14e with the sent_count removed.
Nice job
I
On Wed, Aug 17, 2016 at 04:02:45PM +0800, Xin Long wrote:
> >> you mean only this two line:
> >>> + unsigned long prsctp_param;
> >>> + int sent_count;ca;
> >>
> >> caused the performance issue ?
> >
> > Right.
> OK, can you remove this line from your patch
> + int sent_count;
>
>> you mean only this two line:
>>> + unsigned long prsctp_param;
>>> + int sent_count;ca;
>>
>> caused the performance issue ?
>
> Right.
OK, can you remove this line from your patch
+ int sent_count;
then test again, thanks.
On Wed, Aug 17, 2016 at 03:42:34PM +0800, Aaron Lu wrote:
> On 08/17/2016 03:35 PM, Xin Long wrote:
> >> include/net/sctp/structs.h | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> >> index d8e464aacb20..932f2780d3a4 100
On 08/17/2016 03:35 PM, Xin Long wrote:
>> include/net/sctp/structs.h | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
>> index d8e464aacb20..932f2780d3a4 100644
>> --- a/include/net/sctp/structs.h
>> +++ b/include/net/sctp/stru
> include/net/sctp/structs.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index d8e464aacb20..932f2780d3a4 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -602,6 +602,9 @@ struct sctp_chunk {
On Wed, Aug 17, 2016 at 02:37:19PM +0800, Aaron Lu wrote:
> On Wed, Aug 17, 2016 at 02:14:05PM +0800, Aaron Lu wrote:
> > On Wed, Aug 17, 2016 at 01:41:04PM +0800, Xin Long wrote:
> > > > The perf-profile data for the two commits are attached(for the case of
> > > > prsctp_enable=1, the perf-profil
On Wed, Aug 17, 2016 at 02:14:05PM +0800, Aaron Lu wrote:
> On Wed, Aug 17, 2016 at 01:41:04PM +0800, Xin Long wrote:
> > > The perf-profile data for the two commits are attached(for the case of
> > > prsctp_enable=1, the perf-profile data doesn't get collected for the 0
> > > case for some reason,
On Wed, Aug 17, 2016 at 01:41:04PM +0800, Xin Long wrote:
> > The perf-profile data for the two commits are attached(for the case of
> > prsctp_enable=1, the perf-profile data doesn't get collected for the 0
> > case for some reason, I'm checking the problem now).
> >
> > The CPU gets much more idl
> The perf-profile data for the two commits are attached(for the case of
> prsctp_enable=1, the perf-profile data doesn't get collected for the 0
> case for some reason, I'm checking the problem now).
>
> The CPU gets much more idle time in the bisected commit a6c2f79287:
>
> 68.89% 0.70%
On 08/17/2016 01:04 PM, Aaron Lu wrote:
> On 08/16/2016 05:56 PM, Xin Long wrote:
>
> I'm testing on Linus' master, can we all use that please?
>
[git] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[mechine]
Intel(R) Xeon(R) CPU E5-2690 v2 @ 3
>
> For commit a6c2f79287 ("sctp: implement prsctp TTL policy"), no matter
> the value of net.sctp.prsctp_enable, the throughput is almost the same:
>
> net.sctp.prsctp_enable = 0
> {
> "netperf.Throughput_Mbps": [
> 2353.311249997
> ]
> }
>
> net.sctp.prsctp_enable = 1
> {
> "netperf
On 08/16/2016 05:56 PM, Xin Long wrote:
I'm testing on Linus' master, can we all use that please?
>>>
>>> [git] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>>>
>>> [mechine]
>>> Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz
>>> mem 62G (66000220K)
>>>
>>> [system]
>>
>
> And I think we should be doing test on:
> commit a6c2f79287 ("sctp: implement prsctp TTL policy") (the bisected one)
> and
> commit 826d253d57 ("sctp: add SCTP_PR_ASSOC_STATUS on sctp sockopt") (its
> immediate parent)
> instead of Linus' master HEAD to avoid other factors.
>
The test result s
>>>
>>> I'm testing on Linus' master, can we all use that please?
>>>
>>
>> [git] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>>
>> [mechine]
>> Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz
>> mem 62G (66000220K)
>>
>> [system]
>> # cat /etc/redhat-release
>> Red Hat Enterprise Li
On 08/16/2016 04:02 PM, Xin Long wrote:
>>
>> I'm testing on Linus' master, can we all use that please?
>>
>
> [git] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> [mechine]
> Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz
> mem 62G (66000220K)
>
> [system]
> # cat /etc/redhat-r
On 08/16/2016 04:02 PM, Xin Long wrote:
>>
>> I'm testing on Linus' master, can we all use that please?
>>
>
> [git] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> [mechine]
> Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz
> mem 62G (66000220K)
>
> [system]
> # cat /etc/redhat-r
>
> I'm testing on Linus' master, can we all use that please?
>
[git] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[mechine]
Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz
mem 62G (66000220K)
[system]
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.3 Beta (Maip
Any update on this, Long?
Regards,
Aaron
On 08/08/2016 10:10 AM, Aaron Lu wrote:
> On Fri, Aug 05, 2016 at 07:53:38PM +0800, Xin Long wrote:
It doesn't make much sense to me. the codes I added cannot be
triggered without enable any pr policies. and I also did the tests in
>>>
>>> It se
On Fri, Aug 05, 2016 at 07:53:38PM +0800, Xin Long wrote:
> >> It doesn't make much sense to me. the codes I added cannot be
> >> triggered without enable any pr policies. and I also did the tests in
> >
> > It seems these pr policies has to be turned on by user space, i.e.
> > netperf in this case
>> It doesn't make much sense to me. the codes I added cannot be
>> triggered without enable any pr policies. and I also did the tests in
>
> It seems these pr policies has to be turned on by user space, i.e.
> netperf in this case?
>
> I checked netperf's source code, it doesn't seem set any optio
On Thu, Jul 28, 2016 at 03:01:36PM +0800, Xin Long wrote:
> On Wed, Jul 27, 2016 at 9:54 AM, kernel test robot
> wrote:
> >
> > FYI, we noticed a -37.2% regression of netperf.Throughput_Mbps due to
> > commit:
> >
> > commit a6c2f792873aff332a4689717c3cd6104f46684c ("sctp: implement prsctp
> > T
34 matches
Mail list logo
