[PATCH] hwpmc(4) changes to use 'mp_maxid' instead of 'mp_ncpus'.

[Joseph Koshy]

jr>  In general we accept vendor patches that are not disruptive even in the
jr>  case that the general communit doesn't perceive the real value.  It is
jr>  important for us to work with and encourage vendors.

Well thats ok, but we need to keep the quality bar too and 'do the
right thing'.

jr>  We're not asking you to support the feature.  It looks like juniper
jr>  already has it tested and working.  We just need someone to review the
jr>  patches and commit them.

The patch offers userland a way to get the kernel to schedule threads
on non-existent CPUS.

So I'm curious to know how it was 'tested' in Juniper.

As for support, I'm the one currently answering questions and fielding
the bug reports about PmcTools.

>  The majority of the kernel already deals with sparse cpu mappings.  That's
>  why we have CPU_ABSENT().  Please look at UMA and ULE for examples of code
>  that I have written which use this macro correctly.  I'm sure there are
>  other places that do as well that I'm not familiar with.

Yes, I suggested changes to kern_pmc.c that use CPU_ABSENT().

>  The kernel has the various cpumasks available in sys/smp.h.  Userland can
>  now use cpusets to find out what processors are available to it.  In the
>  future we are going to replace simple cpumasks with the cpuset_t structure
>  from cpusets so on machines that support more than sizeof(register) * 8
>  processors we will use arrays.

Ok, will read up about cpusets.  A manual page would help.

>  > - How will userland  distinguish between absent CPUs those that
>  >  could be temporarily administratively disabled?
>
>  We don't presently make the distinction to the user.

Ok, we can treat them both as 'missing'.  HWPMC cannot deal with CPUs
that come and go though.

>  The rest of the generic code in the kernel already supports this.

The MD layers need to catch up then?

> Juniper claims to have tested and is using this feature.

Define 'tested'.

> Furthermore, it will get  us a tiny step closer to being able to support
> pluggable cpus in a  virtualized environment.

Ok, but that isn't really relevant to HWPMC.   Virtualized environments do
not usually emulate PMCs.

Thanks,
Koshy