Eric Lee / smarc-fsl-linux-kernel

12 Mar, 2008

1 commit

20 Feb, 2008

1 commit

19 Oct, 2007

1 commit

12 Oct, 2007

4 commits

21 Jul, 2007

2 commits

11 Jul, 2007

1 commit

  • 09bb9ce15   [MIPS] Allow generic spaces.h to be included by platform specific ones ... Browse Code »

    Before this patch, when a platform needed to customize one constant in
    spaces.h, they need to redefine all of them.

    Now they can just redefine one constant and include the generic file
    header at the end:

    #include

    This patch doesn't allow to redefine CAC_BASE, IO_BASE and UNCAC_BASE
    for 32 bits platforms because there's no need to do so.

    This will avoid some macro duplications. It's important specially if
    we'll add complex macros.

    Signed-off-by: Franck Bui-Huu
    Signed-off-by: Ralf Baechle

    delete mode 100644 include/asm-mips/mach-ip32/spaces.h

    Franck Bui-Huu
     

17 Mar, 2007

1 commit

  • f1dbf8e71   [MIPS] IP27, IP35: Fix warnings. ... Browse Code »

    include/asm-mips/mach-ip27/dma-coherence.h:22: warning: 'plat_map_dma_mem' defined but not used
    include/asm-mips/mach-ip27/dma-coherence.h:41: warning: 'plat_unmap_dma_mem' defined but not used
    include/asm-mips/mach-ip32/dma-coherence.h:30: warning: 'plat_map_dma_mem' defined but not used
    include/asm-mips/mach-ip32/dma-coherence.h:63: warning: 'plat_unmap_dma_mem' defined but not used

    These functions are meant to be inlined anyway.

    Signed-off-by: Ralf Baechle

    Ralf Baechle
     

05 Mar, 2007

1 commit

  • 69f7c0a1b   [PATCH] sched: remove SMT nice ... Browse Code »

    Remove the SMT-nice feature which idles sibling cpus on SMT cpus to
    facilitiate nice working properly where cpu power is shared. The idling of
    cpus in the presence of runnable tasks is considered too fragile, easy to
    break with outside code, and the complexity of managing this system if an
    architecture comes along with many logical cores sharing cpu power will be
    unworkable.

    Remove the associated per_cpu_gain variable in sched_domains used only by
    this code.

    Also:

    The reason is that with dynticks enabled, this code breaks without yet
    further tweaks so dynticks brought on the rapid demise of this code. So
    either we tweak this code or kill it off entirely. It was Ingo's preference
    to kill it off. Either way this needs to happen for 2.6.21 since dynticks
    has gone in.

    Signed-off-by: Con Kolivas
    Acked-by: Ingo Molnar
    Cc: Nick Piggin
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Con Kolivas
     

14 Feb, 2007

1 commit

12 Dec, 2006

2 commits

03 Oct, 2006

1 commit

  • 1a8488708   [PATCH] sched: introduce child field in sched_domain ... Browse Code »

    Introduce the child field in sched_domain struct and use it in
    sched_balance_self().

    We will also use this field in cleaning up the sched group cpu_power
    setup(done in a different patch) code.

    Signed-off-by: Suresh Siddha
    Acked-by: Ingo Molnar
    Acked-by: Nick Piggin
    Cc: Paul Jackson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Siddha, Suresh B
     

14 Jul, 2006

1 commit

20 Jun, 2006

1 commit

21 Mar, 2006

1 commit

  • a8433137e   [MIPS] Make I/O helpers more customizable ... Browse Code »

    1. Move ioswab*() and __mem_ioswab*() to mangle-port.h. This gets rid
    of CONFIG_SGI_IP22 from include/asm-mips/io.h.

    2. Pass a virtual address to *ioswab*(). Then we can provide
    mach-specific *ioswab*() and can do every evil thing based on its
    argument. It could be useful on machines which have regions with
    different endian conversion scheme.

    3. Call __swizzle_addr*() _after_ adding mips_io_port_base. This
    unifies the meaning of the argument of __swizzle_addr*() (always
    virtual address). Then mach-specific __swizzle_addr*() can do every
    evil thing based on the argument.

    Signed-off-by: Atsushi Nemoto
    Signed-off-by: Ralf Baechle

    Atsushi Nemoto
     

13 Jan, 2006

1 commit

  • 198e2f181   [PATCH] scheduler cache-hot-autodetect ... Browse Code »

    )

    From: Ingo Molnar

    This is the latest version of the scheduler cache-hot-auto-tune patch.

    The first problem was that detection time scaled with O(N^2), which is
    unacceptable on larger SMP and NUMA systems. To solve this:

    - I've added a 'domain distance' function, which is used to cache
    measurement results. Each distance is only measured once. This means
    that e.g. on NUMA distances of 0, 1 and 2 might be measured, on HT
    distances 0 and 1, and on SMP distance 0 is measured. The code walks
    the domain tree to determine the distance, so it automatically follows
    whatever hierarchy an architecture sets up. This cuts down on the boot
    time significantly and removes the O(N^2) limit. The only assumption
    is that migration costs can be expressed as a function of domain
    distance - this covers the overwhelming majority of existing systems,
    and is a good guess even for more assymetric systems.

    [ People hacking systems that have assymetries that break this
    assumption (e.g. different CPU speeds) should experiment a bit with
    the cpu_distance() function. Adding a ->migration_distance factor to
    the domain structure would be one possible solution - but lets first
    see the problem systems, if they exist at all. Lets not overdesign. ]

    Another problem was that only a single cache-size was used for measuring
    the cost of migration, and most architectures didnt set that variable
    up. Furthermore, a single cache-size does not fit NUMA hierarchies with
    L3 caches and does not fit HT setups, where different CPUs will often
    have different 'effective cache sizes'. To solve this problem:

    - Instead of relying on a single cache-size provided by the platform and
    sticking to it, the code now auto-detects the 'effective migration
    cost' between two measured CPUs, via iterating through a wide range of
    cachesizes. The code searches for the maximum migration cost, which
    occurs when the working set of the test-workload falls just below the
    'effective cache size'. I.e. real-life optimized search is done for
    the maximum migration cost, between two real CPUs.

    This, amongst other things, has the positive effect hat if e.g. two
    CPUs share a L2/L3 cache, a different (and accurate) migration cost
    will be found than between two CPUs on the same system that dont share
    any caches.

    (The reliable measurement of migration costs is tricky - see the source
    for details.)

    Furthermore i've added various boot-time options to override/tune
    migration behavior.

    Firstly, there's a blanket override for autodetection:

    migration_cost=1000,2000,3000

    will override the depth 0/1/2 values with 1msec/2msec/3msec values.

    Secondly, there's a global factor that can be used to increase (or
    decrease) the autodetected values:

    migration_factor=120

    will increase the autodetected values by 20%. This option is useful to
    tune things in a workload-dependent way - e.g. if a workload is
    cache-insensitive then CPU utilization can be maximized by specifying
    migration_factor=0.

    I've tested the autodetection code quite extensively on x86, on 3
    P3/Xeon/2MB, and the autodetected values look pretty good:

    Dual Celeron (128K L2 cache):

    ---------------------
    migration cost matrix (max_cache_size: 131072, cpu: 467 MHz):
    ---------------------
    [00] [01]
    [00]: - 1.7(1)
    [01]: 1.7(1) -
    ---------------------
    cacheflush times [2]: 0.0 (0) 1.7 (1784008)
    ---------------------

    Here the slow memory subsystem dominates system performance, and even
    though caches are small, the migration cost is 1.7 msecs.

    Dual HT P4 (512K L2 cache):

    ---------------------
    migration cost matrix (max_cache_size: 524288, cpu: 2379 MHz):
    ---------------------
    [00] [01] [02] [03]
    [00]: - 0.4(1) 0.0(0) 0.4(1)
    [01]: 0.4(1) - 0.4(1) 0.0(0)
    [02]: 0.0(0) 0.4(1) - 0.4(1)
    [03]: 0.4(1) 0.0(0) 0.4(1) -
    ---------------------
    cacheflush times [2]: 0.0 (33900) 0.4 (448514)
    ---------------------

    Here it can be seen that there is no migration cost between two HT
    siblings (CPU#0/2 and CPU#1/3 are separate physical CPUs). A fast memory
    system makes inter-physical-CPU migration pretty cheap: 0.4 msecs.

    8-way P3/Xeon [2MB L2 cache]:

    ---------------------
    migration cost matrix (max_cache_size: 2097152, cpu: 700 MHz):
    ---------------------
    [00] [01] [02] [03] [04] [05] [06] [07]
    [00]: - 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)
    [01]: 19.2(1) - 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)
    [02]: 19.2(1) 19.2(1) - 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)
    [03]: 19.2(1) 19.2(1) 19.2(1) - 19.2(1) 19.2(1) 19.2(1) 19.2(1)
    [04]: 19.2(1) 19.2(1) 19.2(1) 19.2(1) - 19.2(1) 19.2(1) 19.2(1)
    [05]: 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) - 19.2(1) 19.2(1)
    [06]: 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) - 19.2(1)
    [07]: 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) -
    ---------------------
    cacheflush times [2]: 0.0 (0) 19.2 (19281756)
    ---------------------

    This one has huge caches and a relatively slow memory subsystem - so the
    migration cost is 19 msecs.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Ashok Raj
    Signed-off-by: Ken Chen
    Cc:
    Signed-off-by: John Hawkes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    akpm@osdl.org
     

10 Jan, 2006

1 commit

30 Oct, 2005

6 commits

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds