Re: The irq Affinity is changed after the patch(Fixes: b1a5a73e64e9 ("genirq/affinity: Spread vectors on node according to nr_cpu ratio"))

[George Spelvin <lkml@sdf.org>]

On Tue, 19 Nov 2019 at 11:05:55 +0800, chenxiang (M)" <chenxiang66@hisilicon.com> wrote:
> Sorry, I can't access the link you provide, but I can provide those
> irqs' affinity in the attachment.  I also write a small testcase,
> and find id is 1, 2, 3, 0 after calling sort().
> 
> struct ex_s {
>     int id;
>     int cpus;
> };
> struct ex_s ex_total[4] = {
>     {0, 8},
>     {1, 8},
>     {2, 8},
>     {3, 8}
> };
> 
> static int cmp_func(const void *l, const void *r)
> {
>     const struct ex_s *ln = l;
>     const struct ex_s *rn = r;
> 
>     return ln->cpus - rn->cpus;
> }

Your cmp_func is the problem.  sort() in the Linux kernel, like
qsort() in the C library, has never been stable, meaning that if
cmp_func() returns 0, there is no guarantee what order *l and *r
will end up in.  Minor changes to the implementation can change the
result.  You're sorting on the cpus field, which is all 8, so your
cmp_func is saying "I don't care what order the results appear in".

(A web search on "stable sort" will produce decades of discussion
on the subject, but basically an unstable sort has numerous
implementation advantages, and problems can usually be solved by
adjusting the comparison function.)

If you want to sort by ->id if ->cpus is the same, then change the
cmp_func to say so:

static int cmp_func(const void *l, const void *r)
{
    const struct ex_s *ln = l;
    const struct ex_s *rn = r;

    if (ln->cpus != rn->cpus)
	return ln->cpus - rn->cpus;
    else
	return ln->id - rn->id;
}
(This simple subtract-based compare depends on the fact that "cpus"
and "id" are both guaranteed to fit into 31 bits.  If there's any chance
The true difference could exceed INT_MAX, you need to get a bit fancier.)