Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1536990

Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5

From Mel Gorman <mgorman@techsingularity.net>
Newsgroups linux.kernel
Subject Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5
Date 2016-12-06 15:00 +0100
Message-ID <sLorL-2IR-7@gated-at.bofh.it> (permalink)
References (2 earlier) <sJPcJ-8fP-3@gated-at.bofh.it> <sJS0X-1Sd-47@gated-at.bofh.it> <sKRPb-7hu-9@gated-at.bofh.it> <sKYdX-2SD-3@gated-at.bofh.it> <sLdZn-4qN-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Tue, Dec 06, 2016 at 11:43:45AM +0900, Joonsoo Kim wrote:
> > actually clear at all it's an unfair situation, particularly given that the
> > vanilla code is also unfair -- the vanilla code can artifically preserve
> > MIGRATE_UNMOVABLE without any clear indication that it is a universal win.
> > The only deciding factor there was a fault-intensive workload would mask
> > overhead of the page allocator due to page zeroing cost which UNMOVABLE
> > allocations may or may not require. Even that is vague considering that
> > page-table allocations are zeroing even if many kernel allocations are not.
> 
> "Vanilla works like that" doesn't seem to be reasonable to justify
> this change.  Vanilla code works with three lists and it now become
> six lists and each list can have different size of page. We need to
> think that previous approach will also work fine with current one. I
> think that there is a problem although it's not permanent and would be
> minor. However, it's better to fix it when it is found.
> 

This is going in circles. I prototyped the modification which increases
the per-cpu structure slightly and will evaluate. It takes about a day
to run through the full set of tests. If it causes no harm, I'll release
another version.

-- 
Mel Gorman
SUSE Labs

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 0/2] High-order per-cpu cache v5 Mel Gorman <mgorman@techsingularity.net> - 2016-12-02 01:30 +0100
  [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in sync if struct page is corrupted Mel Gorman <mgorman@techsingularity.net> - 2016-12-02 01:30 +0100
    Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in sync if struct page is corrupted "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2016-12-02 05:00 +0100
      Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in  sync if struct page is corrupted Vlastimil Babka <vbabka@suse.cz> - 2016-12-02 07:20 +0100
        Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in sync if struct page is corrupted "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2016-12-02 10:40 +0100
          Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in  sync if struct page is corrupted Michal Hocko <mhocko@kernel.org> - 2016-12-02 11:20 +0100
            Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in  sync if struct page is corrupted Mel Gorman <mgorman@techsingularity.net> - 2016-12-02 12:10 +0100
    Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in  sync if struct page is corrupted Michal Hocko <mhocko@kernel.org> - 2016-12-02 09:20 +0100
      Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in  sync if struct page is corrupted Mel Gorman <mgorman@techsingularity.net> - 2016-12-02 10:50 +0100
        Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in  sync if struct page is corrupted Michal Hocko <mhocko@kernel.org> - 2016-12-02 11:10 +0100
  [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Mel Gorman <mgorman@techsingularity.net> - 2016-12-02 01:30 +0100
    Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-12-02 07:10 +0100
      Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Michal Hocko <mhocko@kernel.org> - 2016-12-02 09:30 +0100
        Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-12-05 04:10 +0100
      Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Mel Gorman <mgorman@techsingularity.net> - 2016-12-02 10:10 +0100
        Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-12-05 04:10 +0100
          Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Mel Gorman <mgorman@techsingularity.net> - 2016-12-05 11:00 +0100
            Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-12-06 03:50 +0100
              Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Mel Gorman <mgorman@techsingularity.net> - 2016-12-06 15:00 +0100
    Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Michal Hocko <mhocko@kernel.org> - 2016-12-02 09:30 +0100

csiph-web