On Thu, Sep 29, 2011 at 05:26:31PM +0200, Johnny Billquist wrote:
And job control is (still) nowhere near the job attaching functions
in TOPS-20. Using things like screen, you get a bit closer...
Hm comparable to VMS' virtual terminals (VTAx:) or the Eumel's or
L3's task attaching?
On Fri, Sep 30, 2011 at 11:27:46AM -0500, David Young wrote:
I don't think that the division of responsibility for power management
between kernel userland is obvious.
It may not be, but the arguments against kernel-level implementation are
largely practical. There is no one size fits all. The
On Thu, Sep 29, 2011 at 02:35:02AM +, David Holland wrote:
I'm sure at this point someone could put together a 36-bit machine out
of FPGAs that ran fast enough to be used as a low-volume web server,
and there are certainly heterogeneity advantages to such a platform.
Maybe someone who
On Thu 29 Sep 2011 at 08:50:24 -0400, Mouse wrote:
The cache and mmu are probably harder than the cpu :-)
I'm not sure the PDP-10 even _had_ cache; I'd have to do some digging
on that score. And I have no idea what it had for an MMU. The only
I think the MMU differed depending on what
On 09/29/2011 02:50 PM, Mouse wrote:
The cache and mmu are probably harder than the cpu :-)
I'm not sure the PDP-10 even _had_ cache; I'd have to do some digging
on that score. And I have no idea what it had for an MMU. The only
non-power-of-two-word-size machine I've ever actually
The cache and mmu are probably harder than the cpu :-)
I'm not sure the PDP-10 even _had_ cache; I'd have to do some digging
on that score. And I have no idea what it had for an MMU. The only
non-power-of-two-word-size machine I've ever actually used, as far as
I can recall, was a
On 2011-09-29 16.01, Rhialto wrote:
On Thu 29 Sep 2011 at 08:50:24 -0400, Mouse wrote:
The cache and mmu are probably harder than the cpu :-)
I'm not sure the PDP-10 even _had_ cache; I'd have to do some digging
on that score. And I have no idea what it had for an MMU. The only
I think
On Thu, Sep 29, 2011 at 09:26:12AM -0500, paul_kon...@dell.com wrote:
The cache and mmu are probably harder than the cpu :-)
I'm not sure the PDP-10 even _had_ cache; I'd have to do some digging
on that score. And I have no idea what it had for an MMU. The only
On Sat, Sep 24, 2011 at 09:22:58PM +0300, Jukka Ruohonen wrote:
And as far as x86 is concerned, the power savings from CPU are really coming
from C-states today. So one can debate whether the 4000 LOC complexity of
Linux's cpufreq subsystem is really worth the trouble.
What's the difference in
On Thu, Sep 29, 2011 at 03:36:03PM -0500, David Young wrote:
What's the difference in power savings between changing C-state and
changing frequency? Do the power savings from every change in C-state
dominate the savings from any change in frequency?
Depends on the machine. But generally on
On Mon, Sep 26, 2011 at 09:17:43PM +0300, Jukka Ruohonen wrote:
On Mon, Sep 26, 2011 at 05:51:13PM +, Christos Zoulas wrote:
Why advertise uint16_t, are we trying to save memory? I would just do
them uint32_t...
While few things are certain in computing, I don't think we are going
On Mon, Sep 26, 2011 at 09:17:43PM +0300, Jukka Ruohonen wrote:
On Mon, Sep 26, 2011 at 05:51:13PM +, Christos Zoulas wrote:
Why advertise uint16_t, are we trying to save memory? I would just do
them uint32_t...
While few things are certain in computing, I don't think we
On Thu, Sep 29, 2011 at 11:42:07AM +1000, matthew green wrote:
Why advertise uint16_t, are we trying to save memory? I would just do
them uint32_t...
While few things are certain in computing, I don't think we are going to
see a 65535 MHz processor any time soon. But sure,
If that periodically-threatened pdp10 port (or some other off-size
port) ever appears, it's not likely to care about the size that
appears in some other environment (unlike for on-disk structures) and
using an explicit size will if anything make life more complicated.
Especially if it's a
On Wed, Sep 28, 2011 at 10:16:29PM -0400, Mouse wrote:
If that periodically-threatened pdp10 port (or some other off-size
port) ever appears, it's not likely to care about the size that
appears in some other environment (unlike for on-disk structures) and
using an explicit size will if
I'm sure at this point someone could put together a 36-bit machine
out of FPGAs that ran fast enough to be used as a low-volume web
server, and there are certainly heterogeneity advantages to such a
platform. Maybe someone who knows enough about such things should
actually do this :-)
If I
On Fri, Sep 23, 2011 at 01:02:52PM +0300, Jukka Ruohonen wrote:
Hello.
The kernel needs a MI interface for CPU frequency scaling. Below is a draft
that is deliberately as simple as possible.
This is NOT about frequency scaling done by the kernel as a governor
(although the long-term goal
On Mon, Sep 26, 2011 at 10:03:06AM -0500, David Young wrote:
Instead, provide an API routine for finding out the number of states
(nstates) and a routine for selecting a state [0, nstates - 1].
The code is ready and it is available in [1]. However, I can not complete it
because when trying to
In article 20110926162557.GA6435@marx.bitnet,
Jukka Ruohonen jruoho...@iki.fi wrote:
On Mon, Sep 26, 2011 at 10:03:06AM -0500, David Young wrote:
Instead, provide an API routine for finding out the number of states
(nstates) and a routine for selecting a state [0, nstates - 1].
The code is
On Mon, Sep 26, 2011 at 05:51:13PM +, Christos Zoulas wrote:
Why advertise uint16_t, are we trying to save memory? I would just do
them uint32_t...
While few things are certain in computing, I don't think we are going to
see a 65535 MHz processor any time soon. But sure, uint32_t is fine
On Sat, Sep 24, 2011 at 07:53:47PM +0200, Joerg Sonnenberger wrote:
I was listening possible decision making factors. Depending on your
environment, you have all or none of them. The main point is that good
decision making needs more than just You can toogle this.
So here is a quick draft for
On Sun, 25 Sep 2011, Jukka Ruohonen wrote:
So here is a quick draft for the first iteration with the cpuctl(8). If there
are issues, speak now, otherwise I'll proceed with something based on this.
You forgot to include the documentation.
--apb (Alan Barrett)
On Sun, Sep 25, 2011 at 10:50:44AM +0200, Alan Barrett wrote:
On Sun, 25 Sep 2011, Jukka Ruohonen wrote:
So here is a quick draft for the first iteration with the cpuctl(8). If
there
are issues, speak now, otherwise I'll proceed with something based on this.
You forgot to include the
jruoho...@iki.fi (Jukka Ruohonen) writes:
But how about
3. { 800 MHz, 805 MHz, 810 MHz, 815 MHz, 820 MHz, 1300 MHz, 1800 MHz }?
4. And how about some ARM system that may export over 30 states,
possibly with non-uniform intervals?
Can outline a consistent algorithm for
On Sat, Sep 24, 2011 at 06:10:46AM +, Michael van Elst wrote:
Pick one low and one high value and select these when the core/cpu/machine
is idle vs. when the machine is busy. Selecting the low and the high
value is much easier for a human when you label it in terms of the
specific platform
On Sat, Sep 24, 2011 at 04:33:07PM +1000, matthew green wrote:
i think that joerg's point is that the kernel-user API is the
wrong place to be making these sorts of humanisations.
You all miss the point that these humanisations (a.k.a. abstractions) are
primarily targeted for the use in
On Sat, Sep 24, 2011 at 09:46:12AM +0300, Jukka Ruohonen wrote:
On Sat, Sep 24, 2011 at 04:33:07PM +1000, matthew green wrote:
i think that joerg's point is that the kernel-user API is the
wrong place to be making these sorts of humanisations.
You all miss the point that these
On Sat, Sep 24, 2011 at 10:14:13AM +0200, Joerg Sonnenberger wrote:
For the in-kernel use it should be completely irrelevant what the
property is.
Sigh. Answer my question then.
Any automatic mechanism should only care about the associated properties
(latency, reduction in power consumption
jruoho...@iki.fi (Jukka Ruohonen) writes:
You all miss the point that these humanisations (a.k.a. abstractions) are
primarily targeted for the use in sys/kern. The kernel-user API is just a
convenient side product of these abstractions.
What is wrong with the abstraction of having a number of
On Sat, Sep 24, 2011 at 08:35:11AM +, Michael van Elst wrote:
What is wrong with the abstraction of having a number of ordered
performance states? Hiding the states behind something pretending to
be a continuum (wether this is a MHz value or a percentage doesn't matter)
causes confusion.
On Sat, Sep 24, 2011 at 10:14:13AM +0200, Joerg Sonnenberger wrote:
For the in-kernel use it should be completely irrelevant what the
property is. Any automatic mechanism should only care about the
associated properties (latency, reduction in power consumption etc). I
don't see any of that
On Sat, Sep 24, 2011 at 08:41:10PM +0300, Jukka Ruohonen wrote:
Here is a datasheet for unreliable and unknown data:
1. Actual clock rate.
Unreliable.
We all know what est(4) and powernow(4) are like; no policy
should rely on any intermediate values that
On Sat, Sep 24, 2011 at 07:53:47PM +0200, Joerg Sonnenberger wrote:
It's not relevant what the exact clock rate is. It's an approximation.
Just like the TSC frequency won't be measured the same on every boot.
It would be relevant if the interval would be guaranteed to be uniform.
Ignoring
What a boolean gives you is: simplicity and a bias towards performance
(which I think should be the priority on NetBSD generally). This is traded
for minor power consumption increase and possibly heat. Should be fine for
servers and most laptop users.
this is not fine for my laptop.
i tend
On Sun, Sep 25, 2011 at 07:06:35AM +1000, matthew green wrote:
(FWIW, ultrasparcIIIi has cpufreq features, iirc, it allows the freq
to run at 1/2 and 1/16th normal. i'm sure that the modern fijitsu
SPARC64 also has it, but i don't know much about it.)
When one thinks about the modern world
Hello.
The kernel needs a MI interface for CPU frequency scaling. Below is a draft
that is deliberately as simple as possible.
This is NOT about frequency scaling done by the kernel as a governor
(although the long-term goal should point to that direction). The present
goal is just to add a
On Fri, Sep 23, 2011 at 01:02:52PM +0300, Jukka Ruohonen wrote:
[2] Note that even in the x86 land it is no longer necessarily known which
is the exact MHz at which the CPU currently runs (cf. TurboBoost, etc.).
TurboBoost is a good reason for why percent is a bad measurement as
well. In
On Fri, Sep 23, 2011 at 08:42:16PM +0200, Joerg Sonnenberger wrote:
On Fri, Sep 23, 2011 at 01:02:52PM +0300, Jukka Ruohonen wrote:
[2] Note that even in the x86 land it is no longer necessarily known which
is the exact MHz at which the CPU currently runs (cf. TurboBoost, etc.).
On Fri, Sep 23, 2011 at 10:40:07PM +0300, Jukka Ruohonen wrote:
On Fri, Sep 23, 2011 at 08:42:16PM +0200, Joerg Sonnenberger wrote:
On Fri, Sep 23, 2011 at 01:02:52PM +0300, Jukka Ruohonen wrote:
[2] Note that even in the x86 land it is no longer necessarily known which
is the exact
On Sat, Sep 24, 2011 at 07:20:16AM +0200, Joerg Sonnenberger wrote:
You can not avoid providing a list of available states. Such an
interface is inherently and completely broken.
Heh, right. Why?
Nor do I see any real difference whether an user sets the CPU frequency to
{ 16 %, 35 %, 100 %
40 matches
Mail list logo
