All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aaron Lu <aaron.lu@intel.com>
To: lkp@lists.01.org
Subject: Re: [sctp] a6c2f79287: netperf.Throughput_Mbps -37.2% regression
Date: Thu, 18 Aug 2016 11:21:56 +0800	[thread overview]
Message-ID: <20160818032156.GA5250@aaronlu.sh.intel.com> (raw)
In-Reply-To: <CADvbK_fGg=QUxaKAZYei+4DLYW4QDzVaGWTC5GEP2+t42AjmSQ@mail.gmail.com>

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

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 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.

This doesn't work.
 
> 2)
> if 1) still doesn't work, I may think about to drop prsctp_param in
> sctp_chunk, and reuse msg->expire_at. as for sent_count, I will
> put it to the mem hole of sctp_chunk.
> 
> So pls also try the attachment patch,  on top of commit a6c2f792873a

Good news, this brings the performance back on my Sandybridge desktop :)
I have queued jobs to the Ivybridge test box but I guess the result is
the same, but will let you know if it isn't.

It looks like the size of the structure plays a role here, but not clear
to me what happened underneath. Do you know why?

Thanks,
Aaron

> 
> Thanks.

> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index 6bcda71..008cb76 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -524,7 +524,11 @@ struct sctp_datamsg {
>  	struct list_head chunks;
>  	/* Reference counting. */
>  	atomic_t refcnt;
> -	/* When is this message no longer interesting to the peer? */
> +	/* Re-use this field to record param for prsctp policies,
> +	 * for TTL policy, it is the time_to_drop of this chunk,
> +	 * for RTX policy, it is the max_sent_count of this chunk,
> +	 * for PRIO policy, it is the priority of this chunk.
> +	 */
>  	unsigned long expires_at;
>  	/* Did the messenge fail to send? */
>  	int send_error;
> @@ -553,6 +557,9 @@ struct sctp_chunk {
>  
>  	atomic_t refcnt;
>  
> +	/* How many times this chunk have been sent, for prsctp RTX policy */
> +	int sent_count;
> +
>  	/* This is our link to the per-transport transmitted list.  */
>  	struct list_head transmitted_list;
>  
> @@ -602,16 +609,6 @@ struct sctp_chunk {
>  	/* This needs to be recoverable for SCTP_SEND_FAILED events. */
>  	struct sctp_sndrcvinfo sinfo;
>  
> -	/* We use this field to record param for prsctp policies,
> -	 * for TTL policy, it is the time_to_drop of this chunk,
> -	 * for RTX policy, it is the max_sent_count of this chunk,
> -	 * for PRIO policy, it is the priority of this chunk.
> -	 */
> -	unsigned long prsctp_param;
> -
> -	/* How many times this chunk have been sent, for prsctp RTX policy */
> -	int sent_count;
> -
>  	/* Which association does this belong to?  */
>  	struct sctp_association *asoc;
>  
> diff --git a/net/sctp/chunk.c b/net/sctp/chunk.c
> index 2698d12..0c53d64 100644
> --- a/net/sctp/chunk.c
> +++ b/net/sctp/chunk.c
> @@ -349,7 +349,7 @@ int sctp_chunk_abandoned(struct sctp_chunk *chunk)
>  	}
>  
>  	if (SCTP_PR_TTL_ENABLED(chunk->sinfo.sinfo_flags) &&
> -	    time_after(jiffies, chunk->prsctp_param)) {
> +	    time_after(jiffies, chunk->msg->expires_at)) {
>  		if (chunk->sent_count)
>  			chunk->asoc->abandoned_sent[SCTP_PR_INDEX(TTL)]++;
>  		else
> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
> index 2c431ee..c7110a9 100644
> --- a/net/sctp/sm_make_chunk.c
> +++ b/net/sctp/sm_make_chunk.c
> @@ -718,7 +718,7 @@ static void sctp_set_prsctp_policy(struct sctp_chunk *chunk,
>  		return;
>  
>  	if (SCTP_PR_TTL_ENABLED(sinfo->sinfo_flags))
> -		chunk->prsctp_param =
> +		chunk->msg->expires_at =
>  			jiffies + msecs_to_jiffies(sinfo->sinfo_timetolive);
>  }
>  


WARNING: multiple messages have this Message-ID (diff)
From: Aaron Lu <aaron.lu@intel.com>
To: Xin Long <lucien.xin@gmail.com>
Cc: kernel test robot <xiaolong.ye@intel.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	lkp@01.org, "David S. Miller" <davem@davemloft.net>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [LKP] [lkp] [sctp] a6c2f79287: netperf.Throughput_Mbps -37.2% regression
Date: Thu, 18 Aug 2016 11:21:56 +0800	[thread overview]
Message-ID: <20160818032156.GA5250@aaronlu.sh.intel.com> (raw)
In-Reply-To: <CADvbK_fGg=QUxaKAZYei+4DLYW4QDzVaGWTC5GEP2+t42AjmSQ@mail.gmail.com>

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 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.

This doesn't work.
 
> 2)
> if 1) still doesn't work, I may think about to drop prsctp_param in
> sctp_chunk, and reuse msg->expire_at. as for sent_count, I will
> put it to the mem hole of sctp_chunk.
> 
> So pls also try the attachment patch,  on top of commit a6c2f792873a

Good news, this brings the performance back on my Sandybridge desktop :)
I have queued jobs to the Ivybridge test box but I guess the result is
the same, but will let you know if it isn't.

It looks like the size of the structure plays a role here, but not clear
to me what happened underneath. Do you know why?

Thanks,
Aaron

> 
> Thanks.

> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index 6bcda71..008cb76 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -524,7 +524,11 @@ struct sctp_datamsg {
>  	struct list_head chunks;
>  	/* Reference counting. */
>  	atomic_t refcnt;
> -	/* When is this message no longer interesting to the peer? */
> +	/* Re-use this field to record param for prsctp policies,
> +	 * for TTL policy, it is the time_to_drop of this chunk,
> +	 * for RTX policy, it is the max_sent_count of this chunk,
> +	 * for PRIO policy, it is the priority of this chunk.
> +	 */
>  	unsigned long expires_at;
>  	/* Did the messenge fail to send? */
>  	int send_error;
> @@ -553,6 +557,9 @@ struct sctp_chunk {
>  
>  	atomic_t refcnt;
>  
> +	/* How many times this chunk have been sent, for prsctp RTX policy */
> +	int sent_count;
> +
>  	/* This is our link to the per-transport transmitted list.  */
>  	struct list_head transmitted_list;
>  
> @@ -602,16 +609,6 @@ struct sctp_chunk {
>  	/* This needs to be recoverable for SCTP_SEND_FAILED events. */
>  	struct sctp_sndrcvinfo sinfo;
>  
> -	/* We use this field to record param for prsctp policies,
> -	 * for TTL policy, it is the time_to_drop of this chunk,
> -	 * for RTX policy, it is the max_sent_count of this chunk,
> -	 * for PRIO policy, it is the priority of this chunk.
> -	 */
> -	unsigned long prsctp_param;
> -
> -	/* How many times this chunk have been sent, for prsctp RTX policy */
> -	int sent_count;
> -
>  	/* Which association does this belong to?  */
>  	struct sctp_association *asoc;
>  
> diff --git a/net/sctp/chunk.c b/net/sctp/chunk.c
> index 2698d12..0c53d64 100644
> --- a/net/sctp/chunk.c
> +++ b/net/sctp/chunk.c
> @@ -349,7 +349,7 @@ int sctp_chunk_abandoned(struct sctp_chunk *chunk)
>  	}
>  
>  	if (SCTP_PR_TTL_ENABLED(chunk->sinfo.sinfo_flags) &&
> -	    time_after(jiffies, chunk->prsctp_param)) {
> +	    time_after(jiffies, chunk->msg->expires_at)) {
>  		if (chunk->sent_count)
>  			chunk->asoc->abandoned_sent[SCTP_PR_INDEX(TTL)]++;
>  		else
> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
> index 2c431ee..c7110a9 100644
> --- a/net/sctp/sm_make_chunk.c
> +++ b/net/sctp/sm_make_chunk.c
> @@ -718,7 +718,7 @@ static void sctp_set_prsctp_policy(struct sctp_chunk *chunk,
>  		return;
>  
>  	if (SCTP_PR_TTL_ENABLED(sinfo->sinfo_flags))
> -		chunk->prsctp_param =
> +		chunk->msg->expires_at =
>  			jiffies + msecs_to_jiffies(sinfo->sinfo_timetolive);
>  }
>  

  reply	other threads:[~2016-08-18  3:21 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-27  1:54 [sctp] a6c2f79287: netperf.Throughput_Mbps -37.2% regression kernel test robot
2016-07-27  1:54 ` [lkp] " kernel test robot
2016-07-28  7:01 ` Xin Long
2016-07-28  7:01   ` [lkp] " Xin Long
2016-08-05  3:31   ` Aaron Lu
2016-08-05  3:31     ` [LKP] [lkp] " Aaron Lu
2016-08-05 11:53     ` Xin Long
2016-08-05 11:53       ` [LKP] [lkp] " Xin Long
2016-08-08  2:10       ` Aaron Lu
2016-08-08  2:10         ` [LKP] [lkp] " Aaron Lu
2016-08-16  2:38         ` Aaron Lu
2016-08-16  2:38           ` [LKP] [lkp] " Aaron Lu
2016-08-16  8:02         ` Xin Long
2016-08-16  8:02           ` [LKP] [lkp] " Xin Long
2016-08-16  8:30           ` Aaron Lu
2016-08-16  8:30             ` [LKP] [lkp] " Aaron Lu
2016-08-16  8:51           ` Aaron Lu
2016-08-16  8:51             ` [LKP] [lkp] " Aaron Lu
2016-08-16  9:56             ` Xin Long
2016-08-16  9:56               ` [LKP] [lkp] " Xin Long
2016-08-17  5:04               ` Aaron Lu
2016-08-17  5:04                 ` [LKP] [lkp] " Aaron Lu
2016-08-17  5:34                 ` Xin Long
2016-08-17  5:34                   ` [LKP] [lkp] " Xin Long
2016-08-17  5:34                 ` Aaron Lu
2016-08-17  5:34                   ` [LKP] [lkp] " Aaron Lu
2016-08-17  5:41                   ` Xin Long
2016-08-17  5:41                     ` [LKP] [lkp] " Xin Long
2016-08-17  6:14                     ` Aaron Lu
2016-08-17  6:14                       ` [LKP] [lkp] " Aaron Lu
2016-08-17  6:37                       ` Aaron Lu
2016-08-17  6:37                         ` [LKP] [lkp] " Aaron Lu
2016-08-17  6:42                         ` Aaron Lu
2016-08-17  6:42                           ` [LKP] [lkp] " Aaron Lu
2016-08-17  7:35                         ` Xin Long
2016-08-17  7:35                           ` [LKP] [lkp] " Xin Long
2016-08-17  7:42                           ` Aaron Lu
2016-08-17  7:42                             ` [LKP] [lkp] " Aaron Lu
2016-08-17  7:53                             ` Aaron Lu
2016-08-17  7:53                               ` [LKP] [lkp] " Aaron Lu
2016-08-17  8:02                             ` Xin Long
2016-08-17  8:02                               ` [LKP] [lkp] " Xin Long
2016-08-17  8:48                               ` Aaron Lu
2016-08-17  8:48                                 ` [LKP] [lkp] " Aaron Lu
2016-08-17  8:58                                 ` Xin Long
2016-08-17  8:58                                   ` [LKP] [lkp] " Xin Long
2016-08-17  9:20                                   ` Aaron Lu
2016-08-17  9:20                                     ` [LKP] [lkp] " Aaron Lu
2016-08-17 18:06                                     ` Xin Long
2016-08-17 18:06                                       ` [LKP] [lkp] " Xin Long
2016-08-18  3:21                                       ` Aaron Lu [this message]
2016-08-18  3:21                                         ` Aaron Lu
2016-08-18 12:45                                         ` Xin Long
2016-08-18 12:45                                           ` [LKP] [lkp] " Xin Long
2016-08-19  5:29                                           ` Aaron Lu
2016-08-19  5:29                                             ` [LKP] [lkp] " Aaron Lu
2016-08-19  7:19                                             ` Marcelo Ricardo Leitner
2016-08-19  7:19                                               ` [LKP] [lkp] " Marcelo Ricardo Leitner
2016-08-19  7:24                                               ` Aaron Lu
2016-08-19  7:24                                                 ` [LKP] [lkp] " Aaron Lu
2016-08-22 21:44                                                 ` Marcelo Ricardo Leitner
2016-08-22 21:44                                                   ` [LKP] [lkp] " Marcelo Ricardo Leitner
2016-08-23  9:19                                                   ` Aaron Lu
2016-08-23  9:19                                                     ` [LKP] [lkp] " Aaron Lu
2016-09-30  7:05                                                   ` Aaron Lu
2016-09-30  7:05                                                     ` [LKP] [lkp] " Aaron Lu
2016-10-03  2:32                                                     ` Xin Long
2016-10-03  2:32                                                       ` [LKP] [lkp] " Xin Long
2016-10-09  7:41                                                       ` Aaron Lu
2016-10-09  7:41                                                         ` [LKP] [lkp] " Aaron Lu
2016-08-16 18:34             ` Xin Long
2016-08-16 18:34               ` [LKP] [lkp] " Xin Long

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=20160818032156.GA5250@aaronlu.sh.intel.com \
    --to=aaron.lu@intel.com \
    --cc=lkp@lists.01.org \
    /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.