Prev: [PATCH -next] staging/phison: depends on ATA_BMDMA
Next: [GIT PULL] ext4 update for 2.6.35
From: Ralf Baechle on 26 May 2010 13:40
On Wed, May 26, 2010 at 10:27:53AM -0700, Kevin D. Kissell wrote:
> Date: Wed, 26 May 2010 10:27:53 -0700
> From: "Kevin D. Kissell" <kevink(a)paralogos.com>
> To: Ralf Baechle <ralf(a)linux-mips.org>
> CC: Julia Lawall <julia(a)diku.dk>, linux-mips(a)linux-mips.org,
> linux-kernel(a)vger.kernel.org, kernel-janitors(a)vger.kernel.org
> Subject: Affinity Automation (was Re: [PATCH 3/17] arch/mips/kernel: Add
> missing
> read_unlock)
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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?

That was Ingo Molnar. The scheduler is owned by these two guys:

SCHEDULER
M: Ingo Molnar <mingo(a)elte.hu>
M: Peter Zijlstra <peterz(a)infradead.org>
S: Maintained
F: kernel/sched*
F: include/linux/sched.h

I've added them to cc.

Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH -next] staging/phison: depends on ATA_BMDMA
Next: [GIT PULL] ext4 update for 2.6.35