Messages in this thread | | | From | "Davide Libenzi" <> | Subject | Re: Auto-Adaptive scheduler - Final chapter ( the numbers ) ... | Date | Thu, 27 Jan 2000 13:06:42 +0100 |
| |
I want to excuse me to You all guys if my english is not so good to explain my feels but has someone realized that I _want_ to include this patch into the kernel ? I've reported only code and numbers, to be evaluated together with guys that have a experience greater than mine, these are only code and numbers. I _want_ exactly nothing.
So Larry, don't mine my education to leave place for flames that not are well suited in this techincal list, and please stop Your personal crusade against guys that _want_ to change the scheduler and want childs to have bad nightmares thinking about kernel code.
> : The RQ = 2 case give me : > : > : Old = 759000 switches / sec = 1.317 us > : New = 735000 switches / sec = 1.360 us
> I certainly hope that noone would use this as a basis for accepting or > rejecting this patch. For a number of reasons:
> . this shows a 3% difference.
The mathematic is mathematic, and its beauty is that leave no space to politicants ;) If You think that an RQ = 2 can result in 759000 switch / sec, then You're right this is a 3 % difference. But even heavy benchmarks ( SpecWebXX, etc .. ) shows that plotting in a XY graphic the switch / sec versus the RQ length, the curve intersect the line X = 2 in a range for 1200 to 2000. So taking the higher one, results that the patch will give a 0.0086 % performance loose for RQ = 2. And this is mathematic plus real experience.
> My experience with linux and context > switching is that the lack of page coloring can cause different > runs of the same test to vary more than this, so these numbers > may be right and then again, they may not. It's pretty hard to > know for sure because you don't know how the OS placed the pages. > The page placement can make all the difference in whether you > collide or fit in the cache.
As Your great experience taught me these are the lower limit of a 16 test set.
> . the real measure of any change is whether or not it increases or > decreases the amount of code in the icache, the number of mispredicted > branches in the icache, the amount of data in the dcache, and finally, > any changes in the number of cache misses.
This is the code ( sorry I forgot to include the bench software ) used to test :
<CODE> /* * Original version by Willy Terreau * Modified by Davide Libenzi */ void oneatwork(int thr) { long long int counter = 0; while (!stop) /* Is writed only at the end of the test */ { if (count) /* Is writed only at the end of the test */ ++counter; syscall(158); /* sys_sched_yield() */ } totalwork[thr] = counter; pthread_exit(0); } </CODE>
This is a pure switching time test. It is a _real_ switching test, that can be used to test switching times under _certain_ RQ loads :
vmstat of a "lat_ctx -s 0 20" give no more than 5-6 tasks in RQ
vmstat of a "threads 20 xx" give always an RQ = 20 ( with no need of cost compensation )
Now, as even my sister ( that works in business ) can realize this code is stored entirely in cache, and the write to the counter is onto the process stack. I _want_ this behaviour coz I _want_ a measure of clean switching times by keeping cache issues ot of the test.
> . a toy benchmark which doesn't do anything but context switch > will never shed any light. The reason is this: suppose most > high context switch applications have a cache footprint of size > A and the context switch path has a cache footprint of size C. > The critical point is where A + C == sizeof(L1 cache). An application > which is larger than sizeof(L1 cache) has ``fallen out of the cache'' > and has dramatically worse performance.
> I think people will agree that for all real workloads the "A" part of > the equation is much greater than the A part of the equation in the > typical context switch benchmark. A trivial context switch benchmark > can easily fit in a 4K cache, probably fits in a 1K cache.
> The point is that the benchmark eats up very little of the cache, the > code path in Linux has been kept very small, so a 16K or 32K cache > actually has some room left.
> OK, so you make your change and you benchmark it. As long as the > benchmark size A plus the context switch path C is less or equal > to the cache size, your change will be essentially invisible. If > you can see any difference in the two process case, that's bad. > if we trust the numbers above (I most certainly do not, I'd want > to see cycle counters), then we are seeing 43 nanosecond difference > per context switch. If the numbers were accurate, this would be > looking a lot like a cache miss.
> I'm sure many of you think I'm a raving lunatic to care about one stinking > cache miss. I'm sorry, but the only way you prevent an OS from becoming > bloated is to care about each and every cache miss, each and every cache > line, and actually weigh the cost vs. the benefit.
I'm asking to You Larry ( and to others ) to prove the "dramatically worse performance" ( with low RQ ) of this patch in the same way I've reported my "code and numbers". Or better if You've not time to do it, point me where I can find a test suite that can prove what are You saying. I'll do it for You ( but I don't have an SMP machine :( ). If tests will reports this "dramatically worse performance" of the patch I'll be _really_ happy to give it to my cat for dinner.
> In this case, I certainly don't see these numbers as conclusive, for all I > know, the new code could be faster rather than slower - we need to look at > the cycle counters to find out. If Richard is reading this, I'll bet he > can tell us how to do that, I think he did a patch for that.
As the tons of question marks at the end of my message reveals, and as I've even said, I'm all but sure about the convenience of the patch i nclusion, so We can agree here Larry.
PS: I include the "instrument" used for my measures.
Always with respect, Davide.
-- All this stuff is IMVHO
[unhandled content-type:application/octet-stream] | |