Heavy I/O blocks FreeBSD box for several seconds

[Ivan Voras]

On 11 July 2011 17:07, Andriy Gapon <avg at freebsd.org> wrote:

> Yeah, but what problem is demonstrated here?
> Are we confident that non-even workload is inherently bad?
> E.g.:
> 79.39 + .. + 77.59 < 5 * 80 = 400
> 100.00 + ... + 55.18 ~~ 402 which is more than theoretically possible :-)
> So it would _appear_ that with ULE we get more work out of available CPUs.

It depends... I am not really concerned about the percentages; for
many things, including "green computing" and TurboBoost it is
beneficial to have one loaded CPU core and the rest of them idling (so
they can be slowed down, or the loaded ones "boosted" - if we even
support this).

>>    PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME    CPU COMMAND
>>   1318 kargl       1 103    0   370M   294M CPU0    0   1:31 100.00% sasmp
>>   1319 kargl       1 103    0   370M   294M RUN     1   1:29 100.00% sasmp
>>   1322 kargl       1  99    0   370M   294M CPU2    2   1:03 87.26% sasmp
>>   1320 kargl       1  91    0   370M   294M RUN     3   1:07 60.79% sasmp
>>   1321 kargl       1  89    0   370M   294M CPU3    3   1:06 55.18% sasmp

What I'd like to know is how do the priority calculations come into
this - as the OP's problem sort of reminds of livelocking.

> P.S. Not saying that this is the case here, but I've seen the following scenario
> in real life.  People add only nominal support for some platform in their software
> - when they don't know how to properly implement some feature, they just drop that
> feature or implement it very suboptimally.  Then other people use bad performance
> of that software on that platform as indication that there is something wrong with
> the platform, not the software.

Yes but as a minority platform, it eventually becomes "our" problem...