Subject: Re: [RFC] Scheduler queue implementation ...
To: davidel@xmailserver.org (Davide Libenzi)
Date: Mon, 10 Dec 2001 00:49:33 +0000 (GMT)
Cc: linux-kernel@vger.kernel.org (lkml), alan@lxorguk.ukuu.org.uk (Alan Cox),
        torvalds@transmeta.com (Linus Torvalds)
In-Reply-To: <Pine.LNX.4.40.0112091558190.996-100000@blue1.dev.mcafeelabs.com> from "Davide Libenzi" at Dec 09, 2001 04:33:18 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E16DEdR-0008Tn-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: linux-kernel-owner@vger.kernel.org

> 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);
	else
		...
	

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/