Eric Lee / smarc-fsl-linux-kernel

28 Jul, 2008

1 commit

23 Jul, 2008

1 commit

  • 422037baf   sched: fix hrtick & generic-ipi dependency ... Browse Code »

    Andrew Morton reported this s390 allmodconfig build failure:

    kernel/built-in.o: In function `hrtick_start_fair':
    sched.c:(.text+0x69c6): undefined reference to `__smp_call_function_single'

    the reason is that s390 is not a generic-ipi SMP platform yet, while
    the hrtick code relies on it. Fix the dependency.

    Signed-off-by: Ingo Molnar

    Ingo Molnar
     

20 Jul, 2008

1 commit

  • 31656519e   sched, x86: clean up hrtick implementation ... Browse Code »

    random uvesafb failures were reported against Gentoo:

    http://bugs.gentoo.org/show_bug.cgi?id=222799

    and Mihai Moldovan bisected it back to:

    > 8f4d37ec073c17e2d4aa8851df5837d798606d6f is first bad commit
    > commit 8f4d37ec073c17e2d4aa8851df5837d798606d6f
    > Author: Peter Zijlstra
    > Date: Fri Jan 25 21:08:29 2008 +0100
    >
    > sched: high-res preemption tick

    Linus suspected it to be hrtick + vm86 interaction and observed:

    > Btw, Peter, Ingo: I think that commit is doing bad things. They aren't
    > _incorrect_ per se, but they are definitely bad.
    >
    > Why?
    >
    > Using random _TIF_WORK_MASK flags is really impolite for doing
    > "scheduling" work. There's a reason that arch/x86/kernel/entry_32.S
    > special-cases the _TIF_NEED_RESCHED flag: we don't want to exit out of
    > vm86 mode unnecessarily.
    >
    > See the "work_notifysig_v86" label, and how it does that
    > "save_v86_state()" thing etc etc.

    Right, I never liked having to fiddle with those TIF flags. Initially I
    needed it because the hrtimer base lock could not nest in the rq lock.
    That however is fixed these days.

    Currently the only reason left to fiddle with the TIF flags is remote
    wakeups. We cannot program a remote cpu's hrtimer. I've been thinking
    about using the new and improved IPI function call stuff to implement
    hrtimer_start_on().

    However that does require that smp_call_function_single(.wait=0) works
    from interrupt context - /me looks at the latest series from Jens - Yes
    that does seem to be supported, good.

    Here's a stab at cleaning this stuff up ...

    Mihai reported test success as well.

    Signed-off-by: Peter Zijlstra
    Tested-by: Mihai Moldovan
    Cc: Michal Januszewski
    Cc: Antonino Daplas
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

26 Jan, 2008

1 commit

  • 8f4d37ec0   sched: high-res preemption tick ... Browse Code »

    Use HR-timers (when available) to deliver an accurate preemption tick.

    The regular scheduler tick that runs at 1/HZ can be too coarse when nice
    level are used. The fairness system will still keep the cpu utilisation 'fair'
    by then delaying the task that got an excessive amount of CPU time but try to
    minimize this by delivering preemption points spot-on.

    The average frequency of this extra interrupt is sched_latency / nr_latency.
    Which need not be higher than 1/HZ, its just that the distribution within the
    sched_latency period is important.

    Signed-off-by: Peter Zijlstra
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

08 Dec, 2006

1 commit

  • 40fcfc872   [PATCH] HZ: 300Hz support ... Browse Code »

    Fix two things. Firstly the unit is "Hz" not "HZ". Secondly it is useful
    to have 300Hz support when doing multimedia work. 250 is fine for us in
    Europe but the US frame rate is 30fps (29.99 blah for pedants). 300 gives
    us a tick divisible by both 25 and 30, and for interlace work 50 and 60.
    It's also giving similar performance to 250Hz.

    I'd argue we should remove 250 and add 300, but that might be excess
    disruption for now.

    Signed-off-by: Alan Cox
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alan Cox
     

24 Jun, 2005

1 commit