在 2019/12/8 15:42, George Spelvin 写道:
On Tue, 19 Nov 2019 at 11:05:55 +0800, chenxiang (M)" <chenxiang66@xxxxxxxxxxxxx> 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.)
.
Thank you for your reply, George.
In function ncpus_cmp_func(), it only sorts by ->ncpus (which makes the
affinity a little odd if the cpus of all the nodes are the same though
it doesn't affect the function).
Maybe it is more better to sort by ->id if ->ncpus is the same in the
function.
