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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> +
> +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
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
+
+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;
-
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
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
is
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
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 patch for
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
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
is
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 +445,14 @@ static
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
but
+
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
32 matches
Mail list logo
