freedos fdapm does not affect stability,
as it uses only the "obvious" signs of
idleness. this means that fdapm apmdos
mode never slows down your apps, it only
HLTs if they are really ready for it.
However, I am thinking about an option
like "HLT if apps seem to be bored", to
get more energy saving. But that can cause
slowdown, as you said. CPUIDLE has a mode
which works that way.
Adding HLT to the "call idle handler" function
inside the FreeDOS kernel would be easy, but
I am not sure if HLT is allowed in all systems:
Some EMM386 just suppress HLT anyway. QEMU has
problems with the way of HLT handling in our
EMM386. An idea would be an option "HLT on idle"
for config.sys - would that be okay for you?
How should the option be called?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
FDAPM idle detection does not affect
stability, as it hooks only to places
which are meant to be idle / waiting
related (wait-for-key, dos idle call).
However, you do not get maximum savings
that way. Other tools, like CPUIDLE,
can also try to detect "program is bored"
states and insert extra HLT then, but
that can result in unwanted program
slowdown when misdetections happen.
We could add a config.sys option
HLTIDLE=yes
or something which just does HLT when
DOS is calling the idle call. Would
save a 1kilobyte of RAM compared to
using FDAPM APMDOS, but would also
detect idle state less reliably.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The current stable SVN version of the kernel implements a simple
"HLT while idle" - can be activated via the IDLEHALT option in
the (fd)config.sys file :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: NO
freedos fdapm does not affect stability,
as it uses only the "obvious" signs of
idleness. this means that fdapm apmdos
mode never slows down your apps, it only
HLTs if they are really ready for it.
However, I am thinking about an option
like "HLT if apps seem to be bored", to
get more energy saving. But that can cause
slowdown, as you said. CPUIDLE has a mode
which works that way.
Adding HLT to the "call idle handler" function
inside the FreeDOS kernel would be easy, but
I am not sure if HLT is allowed in all systems:
Some EMM386 just suppress HLT anyway. QEMU has
problems with the way of HLT handling in our
EMM386. An idea would be an option "HLT on idle"
for config.sys - would that be okay for you?
How should the option be called?
Logged In: NO
FDAPM idle detection does not affect
stability, as it hooks only to places
which are meant to be idle / waiting
related (wait-for-key, dos idle call).
However, you do not get maximum savings
that way. Other tools, like CPUIDLE,
can also try to detect "program is bored"
states and insert extra HLT then, but
that can result in unwanted program
slowdown when misdetections happen.
We could add a config.sys option
HLTIDLE=yes
or something which just does HLT when
DOS is calling the idle call. Would
save a 1kilobyte of RAM compared to
using FDAPM APMDOS, but would also
detect idle state less reliably.
Logged In: YES
user_id=309160
raised priority and changed
the summary line ;-)
Logged In: YES
user_id=309160
Originator: NO
The current stable SVN version of the kernel implements a simple
"HLT while idle" - can be activated via the IDLEHALT option in
the (fd)config.sys file :-)