[RFC PATCH v3 3/6] sched: pack small tasks

[catalin.marinas@arm.com (Catalin Marinas)]

On Wed, Mar 27, 2013 at 05:20:28PM +0000, Vincent Guittot wrote:
> On 27 March 2013 17:36, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Wed, Mar 27, 2013 at 02:13:54PM +0000, Peter Zijlstra wrote:
> >> On Wed, 2013-03-27 at 11:18 +0000, Catalin Marinas wrote:
> >> > On Wed, Mar 27, 2013 at 09:00:20AM +0000, Peter Zijlstra wrote:
> >> > > On Wed, 2013-03-27 at 09:54 +0100, Vincent Guittot wrote:
> >> > > > It's not mandatory to have little cores on low numbers even if it's
> >> > > > advised
> >> > >
> >> > > ARGH!
> >> >
> >> > I haven't followed this thread closely, so just a random comment from
> >> > me. An argument from some is that they want to boot Linux on the big CPU
> >> > to be quicker. The most convenient is to have the big CPU at 0.
> >>
> >> I suppose that's almost sensible ;-) I just despair at the amount of
> >> variation that's allowed.
> >>
> >> I'm guessing that swapping cpus in the bootloader or someplace really
> >> early is equally hard in that we (Linux) assume we boot on cpu 0 or
> >> something like that?
> >
> > I think it's worth trying (by changing the CPU topology in the DT). At a
> > quick look, I don't see anything hard-coded in the kernel boot sequence.
> > It uses smp_processor_id() which translates to
> > current_thread_info()->cpu on ARM. I'm not sure how early we need this
> > but it's probably after DT parsing, so we could set 'cpu' to a non-zero
> > value for the booting processor. There are a few tweaks in the arch/arm
> > code code with cpu_logical_map setup (which maps between
> > smp_processor_id and the actual hardware CPU id and assumes 0 is the
> > booting CPU).
> 
> The are few other places in the code that makes the assumption that
> the 1st online CPU is the booting CPU like the disable_nonboot_cpus

Another thing - boot_cpu_init() is using smp_processor_id() before we
get the setup_arch() call where we parse the DT.

-- 
Catalin