problem about ACPI processor procfs

problem about ACPI processor procfs

[Zhang, Rui]

Hello, list

I met some problems when duplicating ACPI processor procfs interface in sysfs.
#cat /proc/acpi/processor/CPU0/limit
Active limit:		P0:T0
User limit:		P0:T0
Thermal limit:	P0,T0

IMO, "Tx" is easy to understand. It indicates the active T-state, T-state set by user and T-state set by thermal (in passive mode).

But what does the "Px" stand for? After reading the code in processor_thermal.c, I don't think user or thermal will change its value.
And I don't know if it's still needed when porting to sysfs.

Best regards,
Zhang.Rui(Ray)
 
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: problem about ACPI processor procfs

[Thomas Renninger]

On Tue, 2007-02-27 at 17:33 +0800, Zhang, Rui wrote:
> Hello, list
> 
> I met some problems when duplicating ACPI processor procfs interface in sysfs.
> #cat /proc/acpi/processor/CPU0/limit
> Active limit:		P0:T0
> User limit:		P0:T0
> Thermal limit:	P0,T0
> 
> IMO, "Tx" is easy to understand. It indicates the active T-state, T-state set by user and T-state set by thermal (in passive mode).
> 
> But what does the "Px" stand for? After reading the code in processor_thermal.c, I don't think user or thermal will change its value.
> And I don't know if it's still needed when porting to sysfs.

Px are P-states, this is cpufreq.
Writing to it will probably interfere with /sys/devices/../cpufreq/*.
x should correspond to the amount of entries in
/sys/devices/../cpufreq/scaling_available_frequencies.

Can't we just get rid of this? Is there any userspace prog that made use
of this in /proc and if was it really useful in any way?

   Thomas

RE: problem about ACPI processor procfs

[Pallipadi, Venkatesh]

Yes. All the things needed are in cpufreq already and I don't think we
need to export things like P-state power etc in /sys. I think we should
be able to remove all P-state stuff in /proc/acpi without adding
anything in cpufreq. 

Thanks,
Venki

>-----Original Message-----
>From: Thomas Renninger [mailto:trenn@suse.de] 
>Sent: Tuesday, February 27, 2007 6:46 AM
>To: Zhang, Rui
>Cc: linux-acpi@vger.kernel.org; Brown, Len; Pallipadi, Venkatesh
>Subject: Re: problem about ACPI processor procfs
>
>On Tue, 2007-02-27 at 17:33 +0800, Zhang, Rui wrote:
>> Hello, list
>> 
>> I met some problems when duplicating ACPI processor procfs 
>interface in sysfs.
>> #cat /proc/acpi/processor/CPU0/limit
>> Active limit:		P0:T0
>> User limit:		P0:T0
>> Thermal limit:	P0,T0
>> 
>> IMO, "Tx" is easy to understand. It indicates the active 
>T-state, T-state set by user and T-state set by thermal (in 
>passive mode).
>> 
>> But what does the "Px" stand for? After reading the code in 
>processor_thermal.c, I don't think user or thermal will change 
>its value.
>> And I don't know if it's still needed when porting to sysfs.
>
>Px are P-states, this is cpufreq.
>Writing to it will probably interfere with /sys/devices/../cpufreq/*.
>x should correspond to the amount of entries in
>/sys/devices/../cpufreq/scaling_available_frequencies.
>
>Can't we just get rid of this? Is there any userspace prog 
>that made use
>of this in /proc and if was it really useful in any way?
>
>   Thomas
>

RE: problem about ACPI processor procfs

[Zhang Rui]

On Tue, 2007-02-27 at 23:19 +0800, Pallipadi, Venkatesh wrote:
> Yes. All the things needed are in cpufreq already and I don't think we
> need to export things like P-state power etc in /sys. I think we should
> be able to remove all P-state stuff in /proc/acpi without adding
> anything in cpufreq. 
> 
OK.
According to the recent cpuidle patches sent by Venki, a new cpuidle
sysfs interface is built under /sys/devices/system/cpu/cpudile/
and the duplication of the processor C state procfs interface is not
needed any more.

But the throttling states interface is still needed, isn't it?

ACPI spec defines two processor throttling control interfaces.
One is "the processor register black's P_CNT register",
and another is the combined _PTC,_TSS and _TPC objects which allows the
number of T states to be dynamic.
But it seems that the processor driver doesn't support the second
interface, right?

Now I suppose that the number of T states is static and here is the
ACPI processor sysfs interface structure:
/sys/devices/acpi_system:00/.../ACPI0007:xx
|-- processor_id
|-- acpi_id
|-- throttling_control
|-- limit_interface
|-- limit
|   |-- active
|   |-- thermal
|   |-- user
|-- throttling
|   |-- state_count
|   |-- active_state
|   |-- T0_states
   ...
|   |-- Tx_states (max T state support)


The processor driver always enable the thermal limit if T states are
supported. IMO, we should merge processor_thermal.c and
processor_throttling.c together as they are both for throttling control.
Then we can set up an interface like this:
/sys/devices/acpi_system:00/.../ACPI0007:xx
|-- processor_id
|-- acpi_id
|-- throttling_control
|-- throttling
|   |-- active_limit
|   |-- thermal_limit
|   |-- user_limit
|   |-- state_count
|   |-- active_state
|   |-- T0_states
   ...
|   |-- Tx_states (max T state support)

> 
> >-----Original Message-----
> >From: Thomas Renninger [mailto:trenn@suse.de] 
> >Sent: Tuesday, February 27, 2007 6:46 AM
> >To: Zhang, Rui
> >Cc: linux-acpi@vger.kernel.org; Brown, Len; Pallipadi, Venkatesh
> >Subject: Re: problem about ACPI processor procfs
> >
> >On Tue, 2007-02-27 at 17:33 +0800, Zhang, Rui wrote:
> >> Hello, list
> >> 
> >> I met some problems when duplicating ACPI processor procfs 
> >interface in sysfs.
> >> #cat /proc/acpi/processor/CPU0/limit
> >> Active limit:		P0:T0
> >> User limit:		P0:T0
> >> Thermal limit:	P0,T0
> >> 
> >> IMO, "Tx" is easy to understand. It indicates the active 
> >T-state, T-state set by user and T-state set by thermal (in 
> >passive mode).
> >> 
> >> But what does the "Px" stand for? After reading the code in 
> >processor_thermal.c, I don't think user or thermal will change 
> >its value.
> >> And I don't know if it's still needed when porting to sysfs.
> >
> >Px are P-states, this is cpufreq.
> >Writing to it will probably interfere with /sys/devices/../cpufreq/*.
> >x should correspond to the amount of entries in
> >/sys/devices/../cpufreq/scaling_available_frequencies.
> >
> >Can't we just get rid of this? Is there any userspace prog 
> >that made use
> >of this in /proc and if was it really useful in any way?
> >
> >   Thomas
> >