Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Mar 2008 11:11:32 +0530
From:      "Joseph Koshy" <joseph.koshy@gmail.com>
To:        "John Baldwin" <jhb@freebsd.org>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: [PATCH] hwpmc(4) changes to use 'mp_maxid' instead of 'mp_ncpus'.
Message-ID:  <84dead720803192241x1b8ee4c5y65cea8dcca79530f@mail.gmail.com>
In-Reply-To: <200803170947.25205.jhb@freebsd.org>
References:  <20080313180805.GA83406@dragon.NUXI.org> <200803141431.53846.jhb@freebsd.org> <84dead720803142243r6c8cc68dm325e7fb925189fd@mail.gmail.com> <200803170947.25205.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
jk> HWPMC is very x86 centric, for obvious reasons.

jhb>  Considering other CPU archictectures support various performance
counters it
jhb>  really shouldn't be designed to be x86-centric even if it is
currently only
jhb>  implemented for x86 CPUs.

Of course.  It isn't DESIGNED as x86-centric---I surveyed
a number of non-x86 PMC implementations when designing the
MI/MD interface inside of hwpmc(4) and when designing the
end-user programming model.

The "obviousness" of HWPMC's current x86-centricity arises from
the fact that only x86 systems are affordable (or available even)
for a hobbyist in my part of the world.

>  Userland cycles are "cheaper". :)

Not so, they cost the same as kernel cycles in the final analysis :).

> I think having both is fine and userland  can choose which to use
> (maxcpus is probably easier to impl but perhaps less  efficient).

Ok.

jk> Looking around, there appear to be lots of nits that need correction.
jk> For one,  the kern.smp sysctl hierarchy is undocumented.

jhb>  Not entirely:

jhb> sysctl -d kern.smp
jhb>  kern.smp: Kernel SMP
jhb>  kern.smp.maxcpus: Max number of CPUs that the system was compiled for.

I stand (partially) corrected :).

Koshy



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?84dead720803192241x1b8ee4c5y65cea8dcca79530f>