xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Yi Sun <yi.y.sun@linux.intel.com>, xen-devel@lists.xenproject.org
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	andrew.cooper3@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, julien.grall@arm.com,
	mengxu@cis.upenn.edu, jbeulich@suse.com, roger.pau@citrix.com
Subject: Re: [RFC v2 04/12] x86: implement data structure and CPU init flow for MBA.
Date: Wed, 09 Aug 2017 09:09:10 +0800	[thread overview]
Message-ID: <1502240950.3636.13.camel@linux.intel.com> (raw)
In-Reply-To: <1500540553-29199-5-git-send-email-yi.y.sun@linux.intel.com>


> @@ -71,7 +78,6 @@ enum psr_feat_type {
>  /*
>   * This structure represents one feature.
>   * cos_max     - The max COS registers number got through CPUID.
> - * cbm_len     - The length of CBM got through CPUID.

As you are moving instead of removing the code, the comment can also
move together with the code (but not get deleted). But if the remove is
on your purpose (which sounds acceptable to me) then it's another thing.

>   * cos_reg_val - Array to store the values of COS registers. One
> entry stores
>   *               the value of one COS register.
>   *               For L3 CAT and L2 CAT, one entry corresponds to one
> COS_ID.
> @@ -80,9 +86,21 @@ enum psr_feat_type {
>   *               cos_reg_val[1] (Code).
>   */
>  struct feat_node {
> -    /* cos_max and cbm_len are common values for all features so far.
> */
> +    /* cos_max is common values for all features so far. */
>      unsigned int cos_max;
> -    unsigned int cbm_len;
> +
> +    /* Feature specific HW info. */
> +    union {
> +        struct {
> +            unsigned int cbm_len;
> +        } cat_info;
> +
> +        struct {
> +            unsigned int thrtl_max;
> +            unsigned int linear;
> +        } mba_info;
> +    };
> +
>      uint32_t cos_reg_val[MAX_COS_REG_CNT];
>  };
>  
> @@ -161,6 +179,7 @@ static DEFINE_PER_CPU(struct psr_assoc,
> psr_assoc);
>   */
>  static struct feat_node *feat_l3;
>  static struct feat_node *feat_l2_cat;
> +static struct feat_node *feat_mba;
>  
>  /* Common functions */
>  #define cat_default_val(len) (0xffffffff >> (32 - (len)))
> @@ -274,22 +293,22 @@ static bool psr_check_cbm(unsigned int cbm_len,
> unsigned long cbm)
>  }
>  
>  /* CAT common functions implementation. */
> -static int cat_init_feature(const struct cpuid_leaf *regs,
> -                            struct feat_node *feat,
> -                            struct psr_socket_info *info,
> -                            enum psr_feat_type type)
> +static int init_alloc_features(const struct cpuid_leaf *regs,

You still initialize the feature one by one, right? In that case
'features' should keep as 'feature'. Also I'm not sure which degree we
can share the code between CAT and MBA. If not much but just bring many
switch-cases and ifs then I tend to introduce a totally new
mba_init_feature().


> @@ -1439,12 +1508,25 @@ static void psr_cpu_init(void)
>  
>          feat = feat_l2_cat;
>          feat_l2_cat = NULL;
> -        if ( !cat_init_feature(&regs, feat, info, FEAT_TYPE_L2_CAT) )
> +        if ( !init_alloc_features(&regs, feat, info,
> FEAT_TYPE_L2_CAT) )
>              feat_props[FEAT_TYPE_L2_CAT] = &l2_cat_props;
>          else
>              feat_l2_cat = feat;
>      }
>  
> +    cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 0, &regs);

Can we cache this sub leaf 0? Currently we call this for every
allocation feature which in my mind is unnecessary.

> +    if ( regs.b & PSR_RESOURCE_TYPE_MBA )
> +    {
> +        cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 3, &regs);
> +
> +        feat = feat_mba;
> +        feat_mba = NULL;
> +        if ( !init_alloc_features(&regs, feat, info, FEAT_TYPE_MBA) )
> +            feat_props[FEAT_TYPE_MBA] = &mba_props;
> +        else
> +            feat_mba = feat;
> +    }
> +
>      info->feat_init = true;

Chao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2017-08-09  1:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-20  8:49 [RFC v2 00/12] Enable Memory Bandwidth Allocation in Xen Yi Sun
2017-07-20  8:49 ` [RFC v2 01/12] docs: create Memory Bandwidth Allocation (MBA) feature document Yi Sun
2017-07-20  8:49 ` [RFC v2 02/12] Rename PSR sysctl/domctl interfaces and xsm policy to make them be general Yi Sun
2017-07-31 14:30   ` Wei Liu
2017-07-20  8:49 ` [RFC v2 03/12] x86: rename 'cbm_type' to 'psr_val_type' to make it general Yi Sun
2017-07-31 14:30   ` Wei Liu
2017-07-20  8:49 ` [RFC v2 04/12] x86: implement data structure and CPU init flow for MBA Yi Sun
2017-07-31 14:30   ` Wei Liu
2017-08-01  0:51     ` Yi Sun
2017-08-09  1:09   ` Chao Peng [this message]
2017-08-09  2:05     ` Yi Sun
2017-07-20  8:49 ` [RFC v2 05/12] x86: implement get hw info " Yi Sun
2017-08-09  1:12   ` Chao Peng
2017-07-20  8:49 ` [RFC v2 06/12] x86: implement get value interface " Yi Sun
2017-07-20  8:49 ` [RFC v2 07/12] x86: implement set value flow " Yi Sun
2017-08-09  1:33   ` Chao Peng
2017-07-20  8:49 ` [RFC v2 08/12] tools: create general interfaces to support psr allocation features Yi Sun
2017-07-31 14:30   ` Wei Liu
2017-08-01  0:56     ` Yi Sun
2017-08-01  9:05       ` Wei Liu
2017-07-20  8:49 ` [RFC v2 09/12] tools: implement the new get hw info interface suitable to all " Yi Sun
2017-07-31 14:30   ` Wei Liu
2017-07-20  8:49 ` [RFC v2 10/12] tools: implemet new get value interface suitable for " Yi Sun
2017-07-31 14:30   ` Wei Liu
2017-08-01  0:57     ` Yi Sun
2017-07-20  8:49 ` [RFC v2 11/12] tools: implemet new set " Yi Sun
2017-07-20  8:49 ` [RFC v2 12/12] docs: add MBA description in docs Yi Sun

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=1502240950.3636.13.camel@linux.intel.com \
    --to=chao.p.peng@linux.intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dario.faggioli@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien.grall@arm.com \
    --cc=kevin.tian@intel.com \
    --cc=mengxu@cis.upenn.edu \
    --cc=roger.pau@citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    --cc=yi.y.sun@linux.intel.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;
as well as URLs for NNTP newsgroup(s).