[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v8 11/24] x86: refactor psr: set value: implement cos id picking flow.
>>> On 10.03.17 at 06:40, <yi.y.sun@xxxxxxxxxxxxxxx> wrote: > On 17-03-09 07:10:33, Jan Beulich wrote: >> >>> On 15.02.17 at 09:49, <yi.y.sun@xxxxxxxxxxxxxxx> wrote: >> > @@ -397,6 +408,25 @@ static int l3_cat_compare_val(const uint64_t val[], >> > return 0; >> > } >> > >> > +static bool l3_cat_fits_cos_max(const uint64_t val[], >> > + const struct feat_node *feat, >> > + unsigned int cos) >> > +{ >> > + uint64_t l3_def_cbm; >> > + >> > + l3_def_cbm = (1ull << feat->info.l3_cat_info.cbm_len) - 1; >> >> Seeing this pattern recur I wonder whether this also wouldn't be >> something that could be stored once in a generic manner, avoiding >> the need for this per-feature callback (cos_max should be common >> to all features too - not the values, but the abstract notion - so >> perhaps get_cos_max() isn't needed as a callback either). >> > DYM to create a member in 'struct feat_node'? E.g: > uint64_t def_val; Yes. All data items applicable to all features should be outside the feature dependent data structures. And which pieces of data to store you should determine by the overall aim of preferably as little feature-specific code as possible, i.e. whatever can be made common with reasonable effort should be made common. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |