“3fe6b49e2f8adc61fef9a22ecc0c3565f9ea468d”上不存在“git@gitcode.net:openeuler/kernel.git”
  1. 09 10月, 2005 1 次提交
  2. 08 9月, 2005 1 次提交
    • P
      [PATCH] cpusets: new __GFP_HARDWALL flag · f90b1d2f
      Paul Jackson 提交于
      Add another GFP flag: __GFP_HARDWALL.
      
      A subsequent "cpuset_zone_allowed" patch will use this flag to mark GFP_USER
      allocations, and distinguish them from GFP_KERNEL allocations.
      
      Allocations (such as GFP_USER) marked GFP_HARDWALL are constrainted to the
      current tasks cpuset.  Other allocations (such as GFP_KERNEL) can steal from
      the possibly larger nearest mem_exclusive cpuset ancestor, if memory is tight
      on every node in the current cpuset.
      
      This patch collides with Mel Gorman's patch to reduce fragmentation in the
      standard buddy allocator, which adds two GFP flags.  This was discussed on
      linux-mm in July.  Most likely, one of his flags for user reclaimable memory
      can be the same as my __GFP_HARDWALL flag, under some generic name meaning its
      user address space memory.
      Signed-off-by: NPaul Jackson <pj@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f90b1d2f
  3. 08 7月, 2005 1 次提交
  4. 22 6月, 2005 2 次提交
    • C
      [PATCH] Periodically drain non local pagesets · 4ae7c039
      Christoph Lameter 提交于
      The pageset array can potentially acquire a huge amount of memory on large
      NUMA systems.  F.e.  on a system with 512 processors and 256 nodes there
      will be 256*512 pagesets.  If each pageset only holds 5 pages then we are
      talking about 655360 pages.With a 16K page size on IA64 this results in
      potentially 10 Gigabytes of memory being trapped in pagesets.  The typical
      cases are much less for smaller systems but there is still the potential of
      memory being trapped in off node pagesets.  Off node memory may be rarely
      used if local memory is available and so we may potentially have memory in
      seldom used pagesets without this patch.
      
      The slab allocator flushes its per cpu caches every 2 seconds.  The
      following patch flushes the off node pageset caches in the same way by
      tying into the slab flush.
      
      The patch also changes /proc/zoneinfo to include the number of pages
      currently in each pageset.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4ae7c039
    • M
      [PATCH] VM: add __GFP_NORECLAIM · 0c35bbad
      Martin Hicks 提交于
      When using the early zone reclaim, it was noticed that allocating new pages
      that should be spread across the whole system caused eviction of local pages.
      
      This adds a new GFP flag to prevent early reclaim from happening during
      certain allocation attempts.  The example that is implemented here is for page
      cache pages.  We want page cache pages to be spread across the whole system,
      and we don't want page cache pages to evict other pages to get local memory.
      Signed-off-by: NMartin Hicks <mort@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0c35bbad
  5. 01 5月, 2005 1 次提交
    • N
      [PATCH] mempool: NOMEMALLOC and NORETRY · b84a35be
      Nick Piggin 提交于
      Mempools have 2 problems.
      
      The first is that mempool_alloc can possibly get stuck in __alloc_pages
      when they should opt to fail, and take an element from their reserved pool.
      
      The second is that it will happily eat emergency PF_MEMALLOC reserves
      instead of going to their reserved pools.
      
      Fix the first by passing __GFP_NORETRY in the allocation calls in
      mempool_alloc.  Fix the second by introducing a __GFP_MEMPOOL flag which
      directs the page allocator not to allocate from the reserve pool.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b84a35be
  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