Dual Mode Power-Saving Computing System

• US 20090193243A1
• Filed: 01/10/2008
• Published: 07/30/2009
• Est. Priority Date: 01/10/2006
• Status: Active Grant

• Current Assignee: CUPP Computing AS
• Original Assignee: CUPP Computing AS
• Inventors: Ely, Omar Nathaniel
• Granted Patent: US 8,065,536 B2
• Time in Patent Office: Days
• US Class Current: 713/2
• CPC Class Codes: G06F 1/3203 Power management, i.e. event-based initiation of a power-saving mode
• CPC Class Codes: G06F 1/3293 by switching to a less power-consuming processor, e.g. sub-CPU
• CPC Class Codes: Y02D 10/00 Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

The present invention relates to a data processing system comprising both a high performance computing sub-system having typical high power consumption and a low performance subsystem requiring less power. The data processing system acts as a single computing device by moving the execution of software from the low performance subsystem to the high performance subsystem when high computing power is needed and vice versa when low computing performance is sufficient, allowing in the latter case to put the high performance subsystem into a power saving state. The invention relates also to related algorithms.

Claims

1-28. -28. (canceled)

29. A data processing system based comprising

a high-performance computing subsystem having high power consumption (HP subsystem),

a low-performance computing subsystem having lower power consumption (LP subsystem) than said HP subsystem, and

a controller comprising a set of interfaces to said HP subsystem, characterized in that said LP subsystem

is operatively in close integration to said controller, and arranged to boot in an initial step from off (200) to power-on (205), keeping said HP sub-system powered-off (210) and to enter (215) a wait state (220), alternatively a state of standby (290) when an inactivity timeout occurs (289) and to return to said wait state (220) on a wake-up event (291);

is configured to control said data processing system to act as a single computing device by moving software execution to one of

a) said HP subsystem when high computing performance is needed (225) by booting said HP subsystem (230, 235) into a booted state (240), transferring control of user interface means to said HP subsystem and running said software to be executed (245,250,255,260),

b) said LP subsystem when low computing performance is sufficient, by transferring control of user interface means to said LP sub-system, stopping said software to be executed, releasing resources (270, 275);

allowing in case b) to put said HP subsystem into a power saving mode finally arriving at step (280, 285, 220).

30. Data processing system according to claim 29, characterized in that said LP subsystem performs at least one task even when said HP subsystem is actively executing said software.

31. Data processing system according to claim 29, characterized in that said data processing system retains said user interface and a use of peripheral devices independent of, on which one of said subsystems said software is executed.

32. Data processing system according to claim 29, characterized in that said subsystems use operating systems being adapted to their respective computing performance.

33. Data processing system according to claim 29, characterized in that said subsystems comprise their own main processing means, graphical processing means and storage means.

34. Data processing system according to claim 29, characterized in that a display means is controlled by

said LP subsystem while said HP subsystem is in said power saving state, and

said HP subsystem while said HP subsystem is executing said software.

35. Data processing system according to claim 29, characterized in that at least one communication link interconnects said HP subsystem with said LP subsystem.

36. Data processing system according to claim 33, characterized in that said communication link provides said connection to said input/output hub on said HP subsystem.

37. Data processing system according to claim 36, characterized in that peripheral devices are shared using said communication link.

38. Data processing system according to claim 29, characterized in that said subsystems share a basic input/output system.

39. Data processing system according to claim 29, characterized in that a decision on which of said subsystems said execution of said software shall be moved to, is indicated by a switch being at least one of

a physical switch,

a selector as a part of said user interface on said display means, and

a result of evaluating a set of predetermined factors internal to said data processing system.

40. Data processing system according to claim 39, characterized in that said switch is arranged to change a connection of peripheral devices to said subsystem, said subsystem being indicated to execute said software.

41. Data processing system according to claim 40, characterized in that said LP subsystem is detachable from said data processing system, providing—

together with necessary power supply and user interface means—

a stand-alone data processing system.

42. Data processing system according to claim 29, characterized In that said low-performance subsystem (LP) is used for at least one of multitasking and server/client protocols within said data processing system, executing tasks on behalf of said HP subsystem.

43. Data processing system according to claim 29, characterized in that said low-performance subsystem (LP) acts as a slave processor for said high-performance subsystem (HP).

44. Data processing system according to claim 29, characterized in that said LP subsystem is arranged to handle ‘

always-on’

tasks.

45. Data processing system according to claim 44, characterized in that said ‘

always-on’

-tasks comprise drivers for radio input/output, audio-applications, wake-up functions.

46. Data processing system according to claim 29, characterized in that said low-performance subsystem (LP) acts as a server for said high-performance subsystem (HP).

47. Data processing system according to claim 29, characterized in that said data processing system is based on “

core logic”

architecture, and said controller is part of said core logic.

48. A method to coordinate a LP subsystem and a HP subsystem in a data processing system in order to transparently move a software to be executed between said subsystems making said subsystems to act as a single computing device, characterized in the following steps:

a) an initial step booting said LP subsystem from off (200) to power-on (205), keeping said HP subsystem powered-off (210);

b) entering (215) a wait state (220);

c) on a need for high computing performance (225), booting said HP subsystem (230, 235) entering a booted state (240);

d) transferring control of user interface means to said HP subsystem and running said software to be executed (245, 250, 255, 260);

e) on an annulment of said need (265) for high computing performance, transferring control of said user interface means to said LP subsystem stopping said software to be executed, releasing resources (270, 27);

f) transferring said HP subsystem into a power-saving mode, finally arriving at step b) (280, 285, 220).

49. Method according to claim 48, characterized in step b) comprising alternatively to enter a state of standby (290) when an inactivity timeout occurs (289) and returning to said wait state (220 on a wake-up event (291).

50. Method according to claim 48, characterized in stopping said software to be executed and saving an reentry point on one of said subsystems—

a first subsystem—

by running a first proc on said first subsystem comprising the steps;

a) gathering information about a first state of said software on said first subsystem comprising allocated resources (300),

b) storing said first state information to a storage means shared by both subsystems (310), closing down said software on said subsystem comprising releasing resources (320), and

d) putting said first subsystem into a passive power saving state.

51. Method according to claim 48, characterized in starting said software to be executed from a defined start point on one of said subsystems not being said first subsystem—

a second subsystem—

by running a second procedure on said second subsystem comprising the steps;

i) fetching said stored information about said first state of said software from said shared storage means (330),

ii) starting up said software on said second subsystem comprising allocating resources according to said saved state information (340),

iii) establishing a second state on said second subsystem corresponding to said first state information (350),

iv) saving said second state information to said storage means shared by both subsystems (360).

52. Method according to claim 50, characterized in that parts of said state information on said storage means are changed dynamically, when said part of said state information is changed.

53. Method according to claim 50, characterized in that parts of said state information on said storage means are updated sequentially as said operating system is in process.

54. Method according to claim 50, characterized in that parts of said state information on said storage means are updated as system resources become available to execute background tasks.