H. Peter Anvin wrote:
dean gaudet wrote:
why do we need another kernel cpuid reading method when
sched_setaffinity exists and cpuid is available in ring3?
Because /dev/cpu/*/cpuid:
a) predates sched_setaffinity by quite a few years
b) is already widely used
c) doesn't have issues with relativ
dean gaudet wrote:
why do we need another kernel cpuid reading method when sched_setaffinity
exists and cpuid is available in ring3?
Because /dev/cpu/*/cpuid:
a) predates sched_setaffinity by quite a few years
b) is already widely used
c) doesn't have issues with relative priorities (using sch
why do we need another kernel cpuid reading method when sched_setaffinity
exists and cpuid is available in ring3?
-dean
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
Yi Yang wrote:
This patch is try 2, it should cover VIA/Cyrix and Transmeta Crusoe, please
help to test it if anybody has VIA/Cyrix and Transmeta Crusoe. This patch just
makes users get cpuid raw data more conveniently by
/sys/devices/syste/cpu/cpu*/cpuid/* without using any userspace application
This patch is try 2, it should cover VIA/Cyrix and Transmeta Crusoe, please
help to test it if anybody has VIA/Cyrix and Transmeta Crusoe. This patch just
makes users get cpuid raw data more conveniently by
/sys/devices/syste/cpu/cpu*/cpuid/* without using any userspace application.
Current cpuid
On Wed, Jan 30, 2008 at 06:22:43AM +0800, Yi Yang wrote:
> On Tue, 2008-01-29 at 09:44 +0100, Sam Ravnborg wrote:
> > > +
> > > +static struct notifier_block __cpuinitdata cpuid_sysfs_cpu_notifier = {
> > > + .notifier_call = cpuid_sysfs_cpu_callback,
> > > +};
> > Data is annotated _cpuintidata
>
On Tue, 2008-01-29 at 09:44 +0100, Sam Ravnborg wrote:
> > +
> > +static struct notifier_block __cpuinitdata cpuid_sysfs_cpu_notifier = {
> > + .notifier_call = cpuid_sysfs_cpu_callback,
> > +};
> Data is annotated _cpuintidata
>
> but
>
> > +
> Data is annotated _cpuintidata
>
> > @@ -217,11
Yi Yang wrote:
Function cpuid has reset ecx to 0 immediate before calling to __cpuid,
so this shouldn't be a problem now.
Unless, of course, you want to get to the information for the higher
CPUID levels.
The easiest way to fix that would be to use cpuid_count() and let
/dev/cpu/*/cpuid tak
On Tue, 2008-01-29 at 23:17 -0800, H. Peter Anvin wrote:
> Yi Yang wrote:
> >>
> >> It's broken, because it doesn't take into account the fact that Intel
> >> broke CPUID level 4 and made it "repeating" (neither did the cpuid char
> >> device, because it predated the Intel braindamage; I've had a
Yi Yang wrote:
It's broken, because it doesn't take into account the fact that Intel
broke CPUID level 4 and made it "repeating" (neither did the cpuid char
device, because it predated the Intel braindamage; I've had a patch for
it privately for a while, but didn't push it upstream because pa
On Tue, 2008-01-29 at 07:51 -0800, H. Peter Anvin wrote:
> Yi Yang wrote:
> > Current cpuid module will create a char device for every logical cpu,
> > when a user cats /dev/cpu/*/cpuid, he/she will enter a limitless loop,
> > the root cause is that cpuid module doesn't decide wether a cpuid level
Yi Yang wrote:
It's broken, because it doesn't take into account the fact that Intel
broke CPUID level 4 and made it "repeating" (neither did the cpuid char
device, because it predated the Intel braindamage; I've had a patch for
it privately for a while, but didn't push it upstream because pa
On Tue, 2008-01-29 at 07:51 -0800, H. Peter Anvin wrote:
> Yi Yang wrote:
> > Current cpuid module will create a char device for every logical cpu,
> > when a user cats /dev/cpu/*/cpuid, he/she will enter a limitless loop,
> > the root cause is that cpuid module doesn't decide wether a cpuid level
Yi Yang wrote:
Current cpuid module will create a char device for every logical cpu,
when a user cats /dev/cpu/*/cpuid, he/she will enter a limitless loop,
the root cause is that cpuid module doesn't decide wether a cpuid level
is valid, it just uses an offset to denote cpuid level and take it to
> +
> +static struct notifier_block __cpuinitdata cpuid_sysfs_cpu_notifier = {
> + .notifier_call = cpuid_sysfs_cpu_callback,
> +};
Data is annotated _cpuintidata
but
> +
Data is annotated _cpuintidata
> @@ -217,11 +445,14 @@ static void __exit cpuid_exit(void)
> {
> int cpu = 0;
>
Current cpuid module will create a char device for every logical cpu,
when a user cats /dev/cpu/*/cpuid, he/she will enter a limitless loop,
the root cause is that cpuid module doesn't decide wether a cpuid level
is valid, it just uses an offset to denote cpuid level and take it to
cpuid instructio
16 matches
Mail list logo
