On Mon, 16 May 2016 10:44:56 +0200, Youcun Liu said: > u64 cache_miss_rate; // the new variable I insert > Besides, I also have trouble in finding out how to feed data into the new > variable from user level application. Three comments: 1) cache_miss_rate is probably a poor thing to fold into scheduling, because it depends a large part on how much the *previous* thing to run on that core left the cache. If you run, and then a CPU-bound process that only touches 16K of your 8M L2 cache runs, when you reschedule, your cache miss rate will be very low. If however that CPU bound job is walking an array and dirties the entire 8M, your cache miss rate will be astronomical until you've repopulated the cache... 2) Trying to update cache miss rate in real time from *userspace* only makes the problem worse, because your own userspace activity ends up impacting the cache warmth of the process you're trying to track... 2a) Oh, and doing so is inherently full of race conditions.... 3) Even if you get the number in there, what exactly do you propose to do with it? How would you modify the scheduling algorithm? Hint: If you think that the scheduler should be including some new piece of information, you should probably stop and ask yourself "Why, with close to 2 decades of improvement by some very smart people, is it not doing so already?"... There's a *very* good chance it's been considered and discarded (possibly multiple times).
Attachment:
pgpDtG3Dl4lPU.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
