[lkml]   [2003]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BENCHMARK] 2.5.59-mm7 with contest
Con Kolivas wrote:

>On Saturday 01 Feb 2003 11:55 am, Nick Piggin wrote:
>>Con Kolivas wrote:
>>>On Saturday 01 Feb 2003 11:37 am, Nick Piggin wrote:
>>>>Con Kolivas wrote:
>>>>>Seems the fix for "reads starves everything" works. Affected the tar
>>>>>loads too?
>>>>Yes, at the cost of throughput, however for now it is probably
>>>>the best way to go. Hopefully anticipatory scheduling will provide
>>>>as good or better kernel compile times and better throughput.
>>>>Con, tell me, are "Loads" normalised to the time they run for?
>>>>Is it possible to get a finer grain result for the load tests?
>>>No, the load is the absolute number of times the load successfully
>>>completed. We battled with the code for a while to see if there were ways
>>>to get more accurate load numbers but if you write a 256Mb file you can
>>>only tell if it completes the write or not; not how much has been written
>>>when you stop the write. Same goes with read etc. The load rate is a more
>>>meaningful number but we haven't gotten around to implementing that in
>>>the result presentation.
>>I don't know how the contest code works, but if you split that into
>>a number of smaller writes it should work?
>Yes it would but the load effect is significantly diminished. By writing a
>file the size==physical ram the load effect is substantial.
Oh yes of course, but I meant just break up the writing of that big file
into smaller write(2)s.

>>>Load rate would be:
>>>loads / ( load_compile_time - no_load_compile_time )
>>I think loads / time_load_ran_for should be ok (ie, give you loads per time
>>interval). This would be more useful if your loads were getting more
>>or less because it is possible that an improvement would lower compile time
>>_and_ loads, but overall the loads were getting done quicker.
>I found the following is how loads occur almost always:
>noload time: 60
>load time kernal a: 80, loads 20
>load time kernel b: 100, loads 40
>load time kernel c: 90, loads 30
>and loads/total time wouldnt show this effect as kernel c would appear to have
>a better load rate
Kernel a would have a rate of .25 l/s, b: .4 l/s, c: .33~ l/s so I b would
be better.

>if there was
>load time kernel d: 80, loads 40
>that would be more significant no?
It would, yes... but it would measure .5 loads per second done.

The noload time is basically constant anyway so I don't think it would add
much value if it were incorporated into the results, but would make the
metric harder to follow than simple "loads per second".

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:32    [W:0.066 / U:2.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site