[lkml]   [2001]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Scheduler queue implementation ...
> What we lose is the mm ( + 1) goodness() but the eventual cost of
> switching mm is melted inside the long execution time ( 50-60 ms ) typical
> of CPU bound tasks ( note that matching MMs does not mean matching cache
> image ).

The mm matching and keeping an mm on the same cpu is critical for a lot of
applications (your 50ms execution time includes 2ms loading the cache from
the other CPU in some cases). Keeping the same mms together on the processor
is critical for certain platforms (eg ARM) but not for x86 so much.

Biasing an mm towards a given CPU is easy with any per cpu queue system.
I've tried a few variants for sticking the same mm tasks together and one
that might work - especially with your two queue setup is:

/* other live users of this mm */
if(new->mm->runnable && is_cpuhog(new))
list_add(&new->run_list, &new->mm->livehog->run_list);

in other words - if we have the mm in flow then throw ourselves onto the
list of cpu hogs adjacent to the other users of that mm.

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:14    [W:0.107 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site