From bugzilla-daemon at libre-soc.org Mon Apr 12 12:51:04 2021 From: bugzilla-daemon at libre-soc.org (bugzilla-daemon at libre-soc.org) Date: Mon, 12 Apr 2021 11:51:04 +0000 Subject: [Libre-soc-isa] [Bug 623] New: Switching off parts of the CPU - power saving Message-ID: https://bugs.libre-soc.org/show_bug.cgi?id=623 Bug ID: 623 Summary: Switching off parts of the CPU - power saving Product: Libre-SOC's first SoC Version: unspecified Hardware: All OS: All Status: CONFIRMED Severity: enhancement Priority: --- Component: Specification Assignee: lkcl at lkcl.net Reporter: addw at phcomp.co.uk CC: libre-soc-isa at lists.libre-soc.org NLnet milestone: --- An idea that I (ADDW) had recently was that we could save power by switching off parts of the CPU. I have written up an outline below: https://libre-soc.org/ISA/power-saving/ I have not been able to get an idea of how long it would take to power up/down part of a CPU. Comments please. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at libre-soc.org Mon Apr 12 13:30:03 2021 From: bugzilla-daemon at libre-soc.org (bugzilla-daemon at libre-soc.org) Date: Mon, 12 Apr 2021 12:30:03 +0000 Subject: [Libre-soc-isa] [Bug 623] Switching off parts of the CPU - power saving In-Reply-To: References: Message-ID: https://bugs.libre-soc.org/show_bug.cgi?id=623 Alain D D Williams changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|lkcl at lkcl.net |addw at phcomp.co.uk -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at libre-soc.org Mon Apr 12 16:31:17 2021 From: bugzilla-daemon at libre-soc.org (bugzilla-daemon at libre-soc.org) Date: Mon, 12 Apr 2021 15:31:17 +0000 Subject: [Libre-soc-isa] [Bug 621] research needed into OpenPOWER Foundation ISA WG RFC process In-Reply-To: References: Message-ID: https://bugs.libre-soc.org/show_bug.cgi?id=621 --- Comment #1 from Alain D D Williams --- Update - FYI I sent an email to the Openpower foundation Hardware Architecture Workgroup asking how to do this and what documents I could share with LibreSOC. I have yet to receive a reply. My understanding of it is that when we want to submit a proposal I just do it. It needs to be in a certain format. The document that I want to share with you is "OpenPOWER HW Architecture WG Charter" (July 2014) - this is about the process of how proposals are made and eventually accepted. This does not have an explicit confidentiality note but is marked "For Discussion Purposes Only OPF HW Arch WG Charter Sub-Commitee" - a phrase about which I wanted some clarification. The HW Architecture Workgroup Discussions is not very busy. The last email was June 2020; 120 since it was started in June 2014. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at libre-soc.org Mon Apr 12 18:56:11 2021 From: bugzilla-daemon at libre-soc.org (bugzilla-daemon at libre-soc.org) Date: Mon, 12 Apr 2021 17:56:11 +0000 Subject: [Libre-soc-isa] [Bug 623] Switching off parts of the CPU - power saving In-Reply-To: References: Message-ID: https://bugs.libre-soc.org/show_bug.cgi?id=623 Jacob Lifshay changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |programmerjake at gmail.com --- Comment #1 from Jacob Lifshay --- I think powering off portions of the cpu could definitely be controlled by the OS, however, powering them back on should be controlled by the cpu hardware -- when it encounters a instruction needing those portions. I'd expect the power-on latency could be on the order of a few 10s or 100s of nanoseconds, at which scale calling out to the OS greatly increases latency. I think it's faster than voltage/frequency switching because V/F switching usually involves adjusting the power-supply voltage, that takes on the order of microseconds, dwarfing the interrupt-to-OS latency. To help the OS decide when to power-off parts of the cpu, I think we need 32-bit saturating counters (16-bit is not enough, 64-bit is overkill, saturating to avoid issues with wrap-around which would happen once a second at 4GHz) of the number of clock cycles since the last time that part was last used. The counter is set to 0 when the cpu part is powered-back-on, even if it didn't end up being used (e.g. mis-speculation). The counters *must* be privileged-only, since they form an excellent side-channel for speculative execution due to mis-speculation still being a use of that hardware. We could have a simple OS-controlled compare register for each part where the part is powered-down if the compare register is < the last-use counter, allowing simple HW power management. If the OS wants finer control, it can set the compare register to 0xFFFFFFFF to force-power-on the part, and to something less than the current counter to power-down the part. I picked < instead of <= so both: 1. 0xFFFFFFFF will never power-down since the counter stops at 0xFFFFFFFF and 0xFFFFFFFF is not < 0xFFFFFFFF. 2. 0 will still power-on the part if it's in use, since the counter is continuously cleared to 0 while the part is in use, and it remains powered on since 0 is not < 0. It might be handy to have a separate register the previous count is copied to when a part is powered-on, allowing the OS to detect edge-cases like the part being used shortly after power-off, allowing the OS to adjust the power-off interval to better optimize for the program's usage patterns. There would be one set of those 32-bit registers (maybe combined into 64-bit registers) for each independent power-zone on the cpu core. The compare field should be set to some reasonable default on core reset, I'd use 10000 as a reasonable first guess. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at libre-soc.org Mon Apr 12 21:48:20 2021 From: bugzilla-daemon at libre-soc.org (bugzilla-daemon at libre-soc.org) Date: Mon, 12 Apr 2021 20:48:20 +0000 Subject: [Libre-soc-isa] [Bug 623] Switching off parts of the CPU - power saving In-Reply-To: References: Message-ID: https://bugs.libre-soc.org/show_bug.cgi?id=623 --- Comment #2 from Alain D D Williams --- If the HW switches back on: * what is the state of the hardware restarted ? If registers are switched on what are the initial values ? This is something that the os might want some say in - zero is not always the answer. Maybe a status bit per hardware component that causes an OS interrupt. I have added comments to the wiki page about: * what do we power down ? * Jacob's comments -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at libre-soc.org Mon Apr 12 22:26:43 2021 From: bugzilla-daemon at libre-soc.org (bugzilla-daemon at libre-soc.org) Date: Mon, 12 Apr 2021 21:26:43 +0000 Subject: [Libre-soc-isa] [Bug 623] Switching off parts of the CPU - power saving In-Reply-To: References: Message-ID: https://bugs.libre-soc.org/show_bug.cgi?id=623 --- Comment #3 from Jacob Lifshay --- We could track state for powered-off parts using something like RISC-V's XS/FS bit-fields: https://github.com/riscv/riscv-isa-manual/blob/1271737463c04cacd98320d820a38f66d1c87dae/src/machine.tex#L871 Status & FS Meaning & XS Meaning\\ \hline 0 & Off & All off \\ 1 & Initial & None dirty or clean, some on\\ 2 & Clean & None dirty, some clean \\ 3 & Dirty & Some dirty \\ Off is where using those instructions causes a interrupt to OS. The Initial state would be where the registers are cleared to 0 or whatever values make sense. If the state is Initial or Off, then registers can be powered-off and cleared back to their initial value when powered back on. If the state is Clean or Dirty, then the registers must stay powered-on, though they could be in a low-power mode. The computational logic can be powered-off in any case. When the OS next has an interrupt, it can check if the counter has gone past some additional limit (since just turning off the logic but leaving the registers powered is a much faster power state to enter/exit, avoiding needing to involve the OS), then switch the state from Clean or Dirty to Off after saving the register states. This will allow the HW to turn off the registers too. We'd want the XS/FS state anyway to speed up context switches, even if we don't use it for power-saving. -- You are receiving this mail because: You are on the CC list for the bug.