dynamicpower-devel

[Dynamicpower-devel] Thread dpmstate support

[derkling m. <der...@gm...>]

While doing some hacks on DynamicPower and I've notices that it miss support
for a thread-related dpmstate definition.
If I look within /proc/PID/task/TID I can't find a "dpmstate" query file,
and thus I'm unable to set this param for a single thread.
We could define only the dpmstate for a thread leader process and than all
spawned threads will inherit that value.

It should be of interest to have such a feature: this will allow
intra-process optimizations.
Is there any reason for that implementation choice?
Do you think it should be possible and interesting to have a thread-specific
dpmstate definition.

Thanks for any clue.
Patrick

[Dynamicpower-devel] Thread dpmstate support

[derkling m. <der...@gm...>]

This is the quite trivial patch to add thread-specific dpmstate setting
using procfs
Patrick

--- linux-2.6.16.2-2.3/fs/proc/base.c   2007-07-06 10:18:14.000000000 +0200
+++ linux-2.6.16.2-derkling/fs/proc/base.c      2007-07-16 11:24:
58.000000000 +0200
@@ -169,6 +169,7 @@

 #ifdef CONFIG_DPM
        PROC_TGID_DPM,
+       PROC_TID_DPM,
 #endif

        /* Add new entries before this */
@@ -270,6 +271,9 @@
 #ifdef CONFIG_AUDITSYSCALL
        E(PROC_TID_LOGINUID, "loginuid", S_IFREG|S_IWUSR|S_IRUGO),
 #endif
+#ifdef CONFIG_DPM
+        E(PROC_TID_DPM,        "dpmstate",  S_IFREG|S_IRUGO|S_IWUSR),
+#endif
        {0,0,NULL,0}
 };

@@ -1845,6 +1849,7 @@
                        break;
 #endif
 #ifdef CONFIG_DPM
+               case PROC_TID_DPM:
                case PROC_TGID_DPM:
                        inode->i_op = &proc_fd_inode_operations;
                        inode->i_fop = &proc_dpm_operations;

Re: [Dynamicpower-devel] Thread dpmstate support

[Todd P. <tod...@gm...>]

On 7/16/07, derkling ml <der...@gm...> wrote:
> While doing some hacks on DynamicPower and I've notices that it miss support
> for a thread-related dpmstate definition.
> If I look within /proc/PID/task/TID I can't find a "dpmstate" query file,
> and thus I'm unable to set this param for a single thread.
> We could define only the dpmstate for a thread leader process and than all
> spawned threads will inherit that value.
>
> It should be of interest to have such a feature: this will allow
> intra-process optimizations.
>  Is there any reason for that implementation choice?
> Do you think it should be possible and interesting to have a thread-specific
> dpmstate definition.

Sounds like a good feature: to the extent per-process power states are
useful, it really should be implemented per-thread.  From what I've
seen of DPM implementations, the per-process power states haven't been
heavily used for whatever reason, possibly that assigning
power/performance tradeoffs to particular processes is an advanced
topic and most folks are primarily concerned with the basics.  It
would be interesting to see a usage of per-thread power states.

-- 
Todd

Re: [Dynamicpower-devel] Thread dpmstate support

[Patrick B. <der...@gm...>]

> Sounds like a good feature: to the extent per-process power states are
> useful, it really should be implemented per-thread. 
Fortunately, since linux implement thread as LWP, the dpmstate info embedded 
within the task_struct is available for threads too. Threads already inherit 
dpmstate from their thread leader... anyway the procfs DPM interface doesn't 
export that param for task but just for processes. The simple patch I've 
posted previously add that feature so that we find a dpmstate attrib even 
within proc task subdirs.

> From what I've 
> seen of DPM implementations, the per-process power states haven't been
> heavily used for whatever reason, possibly that assigning
> power/performance tradeoffs to particular processes is an advanced
> topic and most folks are primarily concerned with the basics.
Me I'm just investigating on those issues.... and I confirm: it's not trivial.
The main issue we are focusing is how to "understand" power/performances 
threadoff for each process. The idea up-to-now is to try infering that 
information by looking at how processes "use" OS services...
Another issue is related to overhead compensation: how much frequently we 
could change OP without losing benefits of operating at the best OP for each 
task.

> It would be interesting to see a usage of per-thread power states.

Regards,
   Patrick


-- 
<---------------------------------------------------------------------------------------------------------->
                                                  DERKLING
                                    LRU 338214 (http://counter.li.org)

  make linux | more > user-firendly 
<---------------------------------------------------------------------------------------------------------->
   Patrick Bellasi <derkling at users dot sourceforge dot net>
   PhD Student on Computer Science at Politecnico di Milano
   
   Contacts:
    - ICQ      344672588
    - MSN      derkling at yahoo dot it
    - Skype    derkling
   
   Personal Sites:
    - Bookmarks        http://del.icio.us/derkling
    - Bibliography     http://www.bibsonomy.org/user/derkling
    - Music taste      http://www.last.fm/user/derkling/
   
   Privacy:
    - GnuPG    0x72ABC1EE (keyserver.linux.it)
       pub     1024D/72ABC1EE 2003-12-04 Patrick Bellasi
       Key fingerprint: 3958 7B5F 36EC D1F8 C752  9589 C3B7 FD49 72AB C1EE
<---------------------------------------------------------------------------------------------------------->