Eric Lee / smarc-fsl-linux-kernel

06 Dec, 2011

1 commit

31 Oct, 2011

1 commit

  • 9984de1a5   kernel: Map most files to use export.h instead of module.h ... Browse Code »

    The changed files were only including linux/module.h for the
    EXPORT_SYMBOL infrastructure, and nothing else. Revector them
    onto the isolated export header for faster compile times.

    Nothing to see here but a whole lot of instances of:

    -#include
    +#include

    This commit is only changing the kernel dir; next targets
    will probably be mm, fs, the arch dirs, etc.

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

05 Oct, 2011

1 commit

12 Sep, 2011

1 commit

28 Jan, 2011

1 commit

  • 8161239a8   rtmutex: Simplify PI algorithm and make highest prio task get lock ... Browse Code »

    In current rtmutex, the pending owner may be boosted by the tasks
    in the rtmutex's waitlist when the pending owner is deboosted
    or a task in the waitlist is boosted. This boosting is unrelated,
    because the pending owner does not really take the rtmutex.
    It is not reasonable.

    Example.

    time1:
    A(high prio) onwers the rtmutex.
    B(mid prio) and C (low prio) in the waitlist.

    time2
    A release the lock, B becomes the pending owner
    A(or other high prio task) continues to run. B's prio is lower
    than A, so B is just queued at the runqueue.

    time3
    A or other high prio task sleeps, but we have passed some time
    The B and C's prio are changed in the period (time2 ~ time3)
    due to boosting or deboosting. Now C has the priority higher
    than B. ***Is it reasonable that C has to boost B and help B to
    get the rtmutex?

    NO!! I think, it is unrelated/unneed boosting before B really
    owns the rtmutex. We should give C a chance to beat B and
    win the rtmutex.

    This is the motivation of this patch. This patch *ensures*
    only the top waiter or higher priority task can take the lock.

    How?
    1) we don't dequeue the top waiter when unlock, if the top waiter
    is changed, the old top waiter will fail and go to sleep again.
    2) when requiring lock, it will get the lock when the lock is not taken and:
    there is no waiter OR higher priority than waiters OR it is top waiter.
    3) In any time, the top waiter is changed, the top waiter will be woken up.

    The algorithm is much simpler than before, no pending owner, no
    boosting for pending owner.

    Other advantage of this patch:
    1) The states of a rtmutex are reduced a half, easier to read the code.
    2) the codes become shorter.
    3) top waiter is not dequeued until it really take the lock:
    they will retain FIFO when it is stolen.

    Not advantage nor disadvantage
    1) Even we may wakeup multiple waiters(any time when top waiter changed),
    we hardly cause "thundering herd",
    the number of wokenup task is likely 1 or very little.
    2) two APIs are changed.
    rt_mutex_owner() will not return pending owner, it will return NULL when
    the top waiter is going to take the lock.
    rt_mutex_next_owner() always return the top waiter.
    will not return NULL if we have waiters
    because the top waiter is not dequeued.

    I have fixed the code that use these APIs.

    need updated after this patch is accepted
    1) Document/*
    2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst

    Signed-off-by: Lai Jiangshan
    LKML-Reference:
    Reviewed-by: Steven Rostedt
    Signed-off-by: Steven Rostedt

    Lai Jiangshan
     

15 Dec, 2009

1 commit

09 Feb, 2008

1 commit

  • 48d13e483   Don't operate with pid_t in rtmutex tester ... Browse Code »

    The proper behavior to store task's pid and get this task later is to get the
    struct pid pointer and get the task with the pid_task() call.

    Make it for rt_mutex_waiter->deadlock_task_pid field.

    Signed-off-by: Pavel Emelyanov
    Cc: "Eric W. Biederman"
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Emelyanov
     

20 Oct, 2007

1 commit

  • ba25f9dcc   Use helpers to obtain task pid in printks ... Browse Code »

    The task_struct->pid member is going to be deprecated, so start
    using the helpers (task_pid_nr/task_pid_vnr/task_pid_nr_ns) in
    the kernel.

    The first thing to start with is the pid, printed to dmesg - in
    this case we may safely use task_pid_nr(). Besides, printks produce
    more (much more) than a half of all the explicit pid usage.

    [akpm@linux-foundation.org: git-drm went and changed lots of stuff]
    Signed-off-by: Pavel Emelyanov
    Cc: Dave Airlie
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Emelyanov
     

17 Oct, 2007

1 commit

  • a4d63e729   kernel/rtmutex-debug.c: cleanups ... Browse Code »

    This patch contains the following cleanups:
    - make the needlessly global variable rt_trace_on static
    - remove the unused global function deadlock_trace_off()

    Signed-off-by: Adrian Bunk
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     

17 Jul, 2007

1 commit

  • 36cf3b5c3   FUTEX: Tidy up the code ... Browse Code »

    The recent PRIVATE and REQUEUE_PI changes to the futex code made it hard to
    read. Tidy it up.

    Signed-off-by: Thomas Gleixner
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Gleixner
     

04 Oct, 2006

1 commit

04 Jul, 2006

2 commits

  • 36c8b5868   [PATCH] sched: cleanup, remove task_t, convert to struct task_struct ... Browse Code »

    cleanup: remove task_t and convert all the uses to struct task_struct. I
    introduced it for the scheduler anno and it was a mistake.

    Conversion was mostly scripted, the result was reviewed and all
    secondary whitespace and style impact (if any) was fixed up by hand.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     
  • 9a11b49a8   [PATCH] lockdep: better lock debugging ... Browse Code »

    Generic lock debugging:

    - generalized lock debugging framework. For example, a bug in one lock
    subsystem turns off debugging in all lock subsystems.

    - got rid of the caller address passing (__IP__/__IP_DECL__/etc.) from
    the mutex/rtmutex debugging code: it caused way too much prototype
    hackery, and lockdep will give the same information anyway.

    - ability to do silent tests

    - check lock freeing in vfree too.

    - more finegrained debugging options, to allow distributions to
    turn off more expensive debugging features.

    There's no separate 'held mutexes' list anymore - but there's a 'held locks'
    stack within lockdep, which unifies deadlock detection across all lock
    classes. (this is independent of the lockdep validation stuff - lockdep first
    checks whether we are holding a lock already)

    Here are the current debugging options:

    CONFIG_DEBUG_MUTEXES=y
    CONFIG_DEBUG_LOCK_ALLOC=y

    which do:

    config DEBUG_MUTEXES
    bool "Mutex debugging, basic checks"

    config DEBUG_LOCK_ALLOC
    bool "Detect incorrect freeing of live mutexes"

    Signed-off-by: Ingo Molnar
    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     

28 Jun, 2006

1 commit