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

[Vincent Guittot]

On 27 March 2013 17:36, Catalin Marinas <catalin.marinas at 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

>
> So if the above works, the scheduler guys can mandate that little CPUs
> are always first and for ARM it would be a matter of getting the right
> CPU topology in the DT (independent of what hw vendors think of CPU
> topology) and booting Linux on CPU 4 etc.
>
> --
> Catalin