1. 08 8月, 2016 1 次提交
  2. 16 9月, 2009 1 次提交
    • K
      ARM: 5701/1: ARM: copy_page.S: take into account the size of the cache line · dca230f0
      Kirill A. Shutemov 提交于
      Optimized version of copy_page() was written with assumption that cache
      line size is 32 bytes. On Cortex-A8 cache line size is 64 bytes.
      
      This patch tries to generalize copy_page() to work with any cache line
      size if cache line size is multiple of 16 and page size is multiple of
      two cache line size.
      
      After this optimization we've got ~25% speedup on OMAP3(tested in
      userspace).
      
      There is test for kernelspace which trigger copy-on-write after fork():
      
       #include <stdlib.h>
       #include <string.h>
       #include <unistd.h>
      
       #define BUF_SIZE (10000*4096)
       #define NFORK 200
      
       int main(int argc, char **argv)
       {
               char *buf = malloc(BUF_SIZE);
               int i;
      
               memset(buf, 0, BUF_SIZE);
      
               for(i = 0; i < NFORK; i++) {
                       if (fork()) {
                               wait(NULL);
                       } else {
                               int j;
      
                               for(j = 0; j < BUF_SIZE; j+= 4096)
                                       buf[j] = (j & 0xFF) + 1;
                               break;
                       }
               }
      
               free(buf);
               return 0;
       }
      
      Before optimization this test takes ~66 seconds, after optimization
      takes ~56 seconds.
      Signed-off-by: NSiarhei Siamashka <siarhei.siamashka@nokia.com>
      Signed-off-by: NKirill A. Shutemov <kirill@shutemov.name>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      dca230f0
  3. 01 9月, 2008 1 次提交
  4. 25 6月, 2006 1 次提交
  5. 10 9月, 2005 1 次提交
  6. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4