[TEST/REVIEW] CPU accounting patches
Scott Long
scottl at samsco.org
Fri Jan 27 12:48:34 PST 2006
Garance A Drosehn wrote:
> At 11:58 AM +0100 1/25/06, Poul-Henning Kamp wrote:
>
>>
>> With my definition you would be more likely to see lower numbers
>> maybe
>> user 0.20 sys 0.03 real 4.00
>>
>> And they would have meaning, they should be pretty much the same
>> no matter what speed your CPU runs at any instant in time.
>>
>> In theory, it should be possible to compare user/sys numbers
>> you collect while running at 75 MHz with the ones you got
>> under full steam at 1600 MHz.
>>
>> In practice however, things that run on the real time, HZ
>> interrupting to run hardclock() for instance, will still make
>> comparison of such numbers quite shaky.
>>
>> But at least they will not be random as they are now.
>
>
> Here at RPI we used to have a mainframe, and we used to charge
> by the CPU second, so I am familiar with that side of the
> question. However, I am not too concerned by it for my own
> interests. For one, we don't charge by CPU second any more. For
> two, even if we did start charging again, we would just come up
> with some other metric, or simply pick a different rate for
> charging.
>
> The other big usage for timing programs is to compare the
> performance of various algorithms. We have always had users who
> cared very much about the accuracy and consistency of such
> measurements, whether or not we were charging people by the "CPU
> second". Based on the above description, the new CPU accounting
> patches will make those comparisons more meaningful, since the
> values measured will be the same no matter what speed the CPU is
> running at. As such, I think it's a good idea, even if we ignore
> the performance improvement.
>
> Rambling part:
>
> Getting back to the question of charging, I can almost convince
> myself that these changes are also a good idea for when those
> values are used for charging. When we (RPI) charged for CPU time,
> we weren't really charging "for CPU seconds". We were charging
> to say "when we are forced to buy a new computer because this
> computer is maxed out, then how much of that load (and thus the
> expense for the new computer) is the fault of any given user?".
>
> Thus, if we had a computer which could vary it's speed, we don't
> really care about "running out of CPU seconds" if the CPU is in
> fact running at half-speed. We only incur the cost of a new
> machine once we "run out of CPU seconds" when it is running at
> *maximum* speed.
>
> Furthermore, if we had a load which was low enough that we
> *could* get it all done by running the CPU at half-speed, then
> we (as the computer center) would *prefer* to run it at half-
> speed. That way, we reduce power and cooling costs. However,
> we will create extreme hostility in our users if we save that
> money, only to charge them twice as much because they are now
> forced to use "twice as many CPU seconds" when we run the CPU
> at half-speed. Oddly enough, consistency is also the big issue
> when it comes to charging. The user expects to see the exact
> same charge every time they run a specific job, and not see
> their charges vary by a dramatic amount due issues they have
> no control over.
>
> Poul-Henning says the values will "not be as random as they are now".
> If someone *is* charging by the CPU second, then they don't want
> those values to be "random". People who receive random bills can
> get really really hostile, perhaps to the point of bringing in
> lawyers. (and I have seen that happen).
>
> So, it seems to me that this change is *always* the behavior that
> everyone would prefer. Yes, we have to describe it. And maybe we
> should call the value something other than "CPU seconds" to make
> that clear, although I don't know what would be a better name. But
> I think I have convinced myself that there is no downside to these
> proposed changes.
>
> ...Assuming the changes work, of course!
>
Just call it 'cpu cycles'. If I have a job that calls nop 1 billion
times, then I expect to get charged for 1 billion cycles regardless of
if it takes 1 second or 5 days to run. I agree completely with your
argument for consistency and that this will improve consistency and
predictability.
Scott
More information about the freebsd-current
mailing list