Hi, When capturing some traces with dynamic tick we were noticing the interrupt latency seems to go up a good amount. If you look at the trace the gpio IRQ is now offset a good amount. Good news I guess is its pretty predictable. * If we couple this with progressively higher latency C-States we see that IO speed can fall by a good amount, especially for PIO mixes. Now if QOS is maintained you may or may-not care. I was wondering what thoughts of optimizing this might be. One thought was if an io-ondemand of some sort was used. It could track interrupt statistics and be feed back into cpu-idle. When there is a high interrupt load period it could shrink the acceptable latency and thus help choose a good a C-State which favors throughput. Some moving average window could be used to track it. Perhaps a new interrupt attribute could be attached at irq request time to allow the tracking of bandwidth important devices. The attached is captured on a .22 kernel. The same should be available in a bit on a .24 kernel. Regards, Richard W.
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| James Bottomley | Re: Announce: Linux-next (Or Andrew's dream :-)) |
| Michal Piotrowski | Re: 2.6.21-rc5-mm4 |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Frans Pop | svc: failed to register lockdv1 RPC service (errno 97). |
| Lovich, Vitali | RE: [PATCH] Packet socket: mmapped IO: PACKET_TX_RING |
git: | |
