Re: PG_zero

From: Martin J. Bligh (mbligh_at_aracnet.com)
Date: 11/01/04

  • Next message: Jesse Barnes: "Re: [PATCH][plugsched 0/28] Pluggable cpu scheduler framework" 
    Date: 	Mon, 01 Nov 2004 10:03:56 -0800
To: Nick Piggin <nickpiggin@yahoo.com.au>, Andrea Arcangeli <andrea@novell.com>

    >> And there was no
    >> need of using two quicklists for cold and hot pages, less resources are
    >> wasted by just using the lru ordering to diferentiate from hot/cold
    >> allocations and hot/cold freeing.
    >
    > Not sure if this is wise. Reclaimed pages should definitely be cache
    > cold. Other freeing is assumed cache hot and LRU ordered on the hot
    > list which seems right... but I think you want the cold list for page
    > reclaim, don't you?

    You're completely correct about the hot vs cold, but I don't think that
    precludes what Andrea is suggesting ... merge into one list and use the
    hot/cold ends. Mmmm ... why did we do that? I think it was to stop cold
    allocations from eating into hot pages - we'd prefer them to fall back
    into the buddy instead.

    >> Obvious improvements would be to implement a long_write_zero(ptr)
    >> operation that doesn't pollute the cache. IIRC it exists on the alpha, I
    >> assume it exists on x86/x86-64 too. But that's incremental on top of
    >> this.
    >>
    >> It seems stable, I'm running it while writing this.
    >>
    >> I guess testing on a memory bound architecture would be more interesting
    >> (more cpus will make it more memory bound somewhat).
    >>
    >> Comments welcome.
    >
    > I have the feeling that it might not be worthwhile doing zero on idle.
    > You've got chance of blowing the cache on zeroing pages that won't be
    > used for a while. If you do uncached writes then you've changed the
    > problem to memory bandwidth (I guess doesn't matter much on UP).

    Yeah, we got bugger-all benefit out of it. The only think it might do
    is lower the latency on inital load-spikes, but basically you end up
    paying the cache fetch cost twice. But ... numbers rule - if you can come
    up with something that helps a real macro benchmark, I'll eat my non-existant
    hat ;-)

    M.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Jesse Barnes: "Re: [PATCH][plugsched 0/28] Pluggable cpu scheduler framework"

    Relevant Pages

    • Re: PG_zero
      ... Other freeing is assumed cache hot and LRU ordered on the hot ... but I think you want the cold list for page ... > reclaim, don't you? ... the current per-cpu lists and those are all fixed, ...
      (Linux-Kernel)
    • Re: [PATCH 20/20] Get rid of the concept of hot/cold page freeing
      ... A profile run of kernbench showed that "cold" ... Things like page cache and pages being truncated are are considered ... giving the page allocator "go faster stripes". ... int bufsize, sizes, iteration; ...
      (Linux-Kernel)
    • Re: [PATCH 20/20] Get rid of the concept of hot/cold page freeing
      ... A profile run of kernbench showed that "cold" ... Things like page cache and pages being truncated are are considered ... but if the system is reclaiming pages, then we have entered allocator ... int bufsize, sizes, iteration; ...
      (Linux-Kernel)
    • Re: PG_zero
      ... After the DMA transfer, all the ... >> cache lines will have to be invalidated in every CPUs cache anyway, ... > becomes hot, something will become cold. ... I wonder if you've any measurement ...
      (Linux-Kernel)
    • Re: PG_zero
      ... After the DMA transfer, all the ... >>cache lines will have to be invalidated in every CPUs cache anyway, ... > becomes hot, something will become cold. ... >>have more work to do in terms of cacheline invalidates. ...
      (Linux-Kernel)