[Top] [All Lists]

Affinity Automation (was Re: [PATCH 3/17] arch/mips/kernel: Add missing

To: Ralf Baechle <>
Subject: Affinity Automation (was Re: [PATCH 3/17] arch/mips/kernel: Add missing read_unlock)
From: "Kevin D. Kissell" <>
Date: Wed, 26 May 2010 10:27:53 -0700
Cc: Julia Lawall <>,,,
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default;; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Vm0t1378OMWxsPQM1fuQfCp+AL44gv1lXjVGrdS0TYtUix2oOCQHP+UYTqmyf48ErG+bz4DbY/GFDscn4iEUMBV2livrpfpjIHbT/aRJtqjMOLQxbV2KduxYTnZwRjGK;
In-reply-to: <>
Original-recipient: rfc822;
References: <> <>
User-agent: Thunderbird (X11/20100317)
Ralf Baechle wrote:
Your patch appears correct - and mipsmt_sys_sched_setaffinity() even
more broken than you thought.  It duplicates some code from kernel/sched.c
and has gotten out of sync.
Yeah, that was inevitable. Since the distribution of the previous message seems to cover concerned developers outside the MIPS community, let me make one final(?) plea to actually do this right.

The MIPS SMTC support for managing a single FPU context on a processor with multiple integer TC contexts involves having the system make automous, real time, decisions about scheduling affinity. It may be a first, but it can't possibly be the only case, especially as we've started seeing more and more mainstream multi-core, multi-thread designs. System and chip resources are going to be "closer" to one processor or another. The current Linux paradigm is that it's the responsibility of programs, or users, to know what the optimal placement of processes should be for a given system platform, and while it's absolutely appropriate to provide that level of control for the cases where the user really does know best, it's mildly insane to make that the only way that thread placement can be optimized. It's really the OS's job to match demand to resources.

My contention years ago was, and remains, that it would be a bad idea to burden the main scheduler loop with checks for two different levels of affinity, system-automatic and user-specified. It would add non-trivially to the cache footprint and execution overhead of thread dispatch, and there's no logical need for it. So the model I proposed, and implemented in the cloned affinity system calls for SMTC, was that a *single* affinity mask continue to be used by the scheduler, but that the per-thread data structures carry two: The one requested explicitly by the user, and the one actually used by the scheduler. The idea is that normally those two are the same, but that the system - in the MIPS SMTC case, the FPU emulator - can overlay its constraints with the user's constraints to come up with an intersection-of-sets constraint that satisfies both (there was a clause which prevents system affinity heuristics from restricting the affinity mask to a null set of CPUs, though of course the user can do that if he really wants to).

There's nothing particularly MIPS-specific about the problem or the solution. Most of the mechanisms should really be in platform-independent code, so we don't get the drift of cloned components.

I don't recall who owned the scheduler at the time, but whoever it was was too busy dealing with mainstream processor problems to even engage in a dialogue about this. Is it time to raise the question again?


         Kevin K.

<Prev in Thread] Current Thread [Next in Thread>