27 Apr, 2007

1 commit


25 Mar, 2007

1 commit


14 Dec, 2006

1 commit

  • Virtually index, physically tagged cache architectures can get away
    without cache flushing when forking. This patch adds a new cache
    flushing function flush_cache_dup_mm(struct mm_struct *) which for the
    moment I've implemented to do the same thing on all architectures
    except on MIPS where it's a no-op.

    Signed-off-by: Ralf Baechle
    Signed-off-by: Linus Torvalds

    Ralf Baechle
     

22 Oct, 2006

1 commit

  • The current implementation uses a sequence of a cacheflush and a copy.
    This is racy in case of a multithreaded debuggee and renders GDB
    virtually unusable.

    Aside this fixes a performance hog rendering access to /proc/cmdline very
    slow and resulting in a enough cache stalls for the 34K AP/SP programming
    model to make the bare metal code on the non-Linux VPE miss RT deadlines.

    The main part of this patch was originally written by Ralf Baechle;
    Atushi Nemoto did the the debugging.

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

    Ralf Baechle
     

02 Oct, 2006

1 commit


27 Sep, 2006

1 commit

  • On the 34K the redundant cache operations were causing excessive stalls
    resulting in realtime code running on the second VPE missing its deadline.
    For all other platforms this patch is just a significant performance
    improvment as illustrated by below benchmark numbers.

    Processor, Processes - times in microseconds - smaller is better
    ------------------------------------------------------------------------------
    Host OS Mhz null null open slct sig sig fork exec sh
    call I/O stat clos TCP inst hndl proc proc proc
    --------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
    25Kf 2.6.18-rc4 533 0.49 1.16 7.57 33.4 30.5 1.34 12.4 5497 17.K 54.K
    25Kf 2.6.18-rc4-p 533 0.49 1.16 6.68 23.0 30.7 1.36 8.55 5030 16.K 48.K
    4Kc 2.6.18-rc4 80 4.21 15.0 131. 289. 261. 16.5 258. 18.K 70.K 227K
    4Kc 2.6.18-rc4-p 80 4.34 13.1 128. 285. 262. 18.2 258. 12.K 52.K 176K
    34Kc 2.6.18-rc4 40 5.01 14.0 61.6 90.0 477. 17.9 94.7 29.K 108K 342K
    34Kc 2.6.18-rc4-p 40 4.98 13.9 61.2 89.7 475. 17.6 93.7 8758 44.K 158K
    BCM1480 2.6.18-rc4 700 0.28 0.60 3.68 5.92 16.0 0.78 5.08 931. 3163 15.K
    BCM1480 2.6.18-rc4-p 700 0.28 0.61 3.65 5.85 16.0 0.79 5.20 395. 1464 8385
    TX49-16K 2.6.18-rc3 197 0.73 2.41 19.0 37.8 82.9 2.94 17.5 4438 14.K 56.K
    TX49-16K 2.6.18-rc3-p 197 0.73 2.40 19.9 36.3 82.9 2.94 23.4 2577 9103 38.K
    TX49-32K 2.6.18-rc3 396 0.36 1.19 6.80 11.8 41.0 1.46 8.17 2738 8465 32.K
    TX49-32K 2.6.18-rc3-p 396 0.36 1.19 6.82 10.2 41.0 1.46 8.18 1330 4638 18.K

    Original patch by me with enhancements by Atsushi Nemoto.

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

    Ralf Baechle
     

19 Apr, 2006

1 commit


07 Feb, 2006

1 commit


30 Oct, 2005

4 commits


17 Apr, 2005

1 commit

  • 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