Re: [PATCH] Avoiding external fragmentation with a placement policy Version 10

[Mel Gorman <mel@csn.ul.ie>]

On Tue, 3 May 2005, Joel Schopp wrote:

> Comments inline below.
>
> > o Tightened what pools are used for fallbacks, less likely to fragment
> > o Many micro-optimisations to have the same performance as the standard
> > allocator. Modified allocator now faster than standard allocator using
> >   gcc 3.3.5
>
> Nice.
>
> > o Increased the size of reserve for fallbacks from 10% to 12.5%.
>
> This just screams out for a tunable.  Systems with different workloads and
> different amounts of memory will behave better with different values.  It
> would be even better if it would self tune, but that might prove difficult.
>

The 12.5% was chosen as it's slightly above what the low-level watermarks
are. I don't think it needs to be a tunable although I agree that
calculating it based on zone watermarks would be a better idea than me
guessing 12.5%.

> > Difference in performance operations report generated by diff-aim9.sh from
> > VMRegress 0.14
> > N  Test          Standard   MBuddy V10  Diff     % diff Test description
> >                  Ops/sec    Ops/sec     Ops/sec
> > -- ----------    ---------  ----------  -------- ------ ----------------
> >  1 add_double    460569.72  465222.46    4652.74  1.01% Thousand Double
> > Precision Additions/second
> >  2 add_float     460523.25  465322.45    4799.20  1.04% Thousand Single
> > Precision Additions/second
> >  3 add_long     1421763.04 1436042.64   14279.60  1.00% Thousand Long
> > Integer Additions/second
> >  4 add_int      1421763.04 1436042.64   14279.60  1.00% Thousand Integer
> > Additions/second
> >  5 add_short    1421363.11 1435760.71   14397.60  1.01% Thousand Short
> > Integer Additions/second
> >  7 page_test     121048.16  123059.49    2011.33  1.66% System Allocations &
> > Pages/second
> >  8 brk_test      445743.79  452407.93    6664.14  1.50% System Memory
> > Allocations/second
> >  9 jmp_test     4158416.67 4232083.33   73666.66  1.77% Non-local
> > gotos/second
> > 10 signal_test    94417.60   94584.24     166.64  0.18% Signal Traps/second
> > 11 exec_test         65.04      66.69       1.65  2.54% Program Loads/second
> > 12 fork_test       1537.82    1730.51     192.69 12.53% Task
> > Creations/second
> > 13 link_test       6411.28    6477.45      66.17  1.03% Link/Unlink
> > Pairs/second
> >
> > The aim9 results show that there are consistent improvements for common
> > page-related operations. The results are compiler dependant and there are
> > variances of 1-2% between versions.
>
> Any explanation for why fork_test shows markedly better improvement compared
> to the others?
>

Not a clue.

> > -#define __GFP_BITS_SHIFT 16 /* Room for 16 __GFP_FOO bits */
> > +#define __GFP_BITS_SHIFT 18 /* Room for 16 __GFP_FOO bits */
>
> Comment should have the new 18, not the old 16.
>

Opps, correct.

> > +#ifdef CONFIG_ALLOCSTATS
> > +    /*
> > +     * These are beancounters that track how the placement policy
> > +     * of the buddy allocator is performing
> > +     */
> > +    unsigned long fallback_count[ALLOC_TYPES];
> > +    unsigned long alloc_count[ALLOC_TYPES];
> > +    unsigned long reserve_count[ALLOC_TYPES];
> > +    unsigned long kernnorclm_full_steal;
> > +    unsigned long kernnorclm_partial_steal;
> > +    unsigned long bulk_requests[MAX_ORDER];
> > +    unsigned long bulk_alloced[MAX_ORDER];
> > +#endif
>
> It would be nice if all of the CONFIG_ALLOCSTATS stuff was broken out as a
> second patch.  It would make this patch much smaller and more readable.
>

I can do that. They were kept as one patch as I almost always collect the
statistics as it's easier to figure out what is happening. I've also found
that benchmark results tend to be better if I collect statistics (which
makes no sense but was consistently true).

> > +int fallback_allocs[ALLOC_TYPES][ALLOC_TYPES] = { + {ALLOC_KERNNORCLM,
> > ALLOC_FALLBACK,   ALLOC_KERNRCLM,   ALLOC_USERRCLM},
> > +    {ALLOC_KERNRCLM,   ALLOC_FALLBACK,   ALLOC_KERNNORCLM, ALLOC_USERRCLM},
>
> I would have thought that KernRclm would want to choose USERRCLM over
> KERNNOCRLM.
>

No, because UserRclm is the easiest to free pages in by far where as
KernRclm pages need a lot more work, specifically the ability to reclaim a
slab page on demand. From the point of view of fragmentation, KernNoRclm
is already lost, so I prefer to fallback there than anywhere else.

The problem is that it can accelerate when a KernNoRclm allocation needs
to fallback. I have not found it to be a problem in the benchmarks I've
run but there may be cases in the future where we need to be a lot more
strict about fallbacks.

> > +    {ALLOC_USERRCLM,   ALLOC_FALLBACK,   ALLOC_KERNNORCLM, ALLOC_KERNRCLM},
>
> I'm almost certain the UserRclm type should prefer KERNRCLM over KERNNORCLM.
>

Again no for similar reasons to why KernRclm falls back to KernNoRclm.

>
> > +     * Here, the alloc type lists has been depleted as well as the global
> > +     * pool, so fallback. When falling back, the largest possible block
> > +     * will be taken to keep the fallbacks clustered if possible
> > +     */
>
> I was curious if you had tried taking the smallest possible block.  I would
> think that it would reduce the amount of fallback needed, and thus increase
> the amount available for the 3 allocation types.  I would expect a net win,
> despite not clustering fallbacks particularly well.
>

I found it to be a net loss on tests with increased fallbacks. If we
fallback on order-0, we'll also fallback on the next allocation. However,
if we "steal" a large block of pages, fallbacks will be delayed until that
large block is consumed.

> > +    alloctype = fallback_list[retry_count];
> > +
> > +    /* Find a block to allocate */
> > +    area = zone->free_area_lists[alloctype] + (MAX_ORDER-1);
> > +    current_order=MAX_ORDER;
> > +    do {
> > +    current_order--;
> > +    if (list_empty(&area->free_list)) {
> > +    area--;
> > +    continue;
> > +    }
> > +
> > +    goto remove_page;
> > +    } while (current_order != order);
> > +    }
>
> This loop is a bit hard to understand.  I think it would be easier to
> understand if it looked something like this (totally untested):
>
> +      current_order=MAX_ORDER - 1 ;
> +      do {
> +      if (!list_empty(&area->free_list)) {
> +      goto remove_page;
> +      }
> +
> +      area--;
> +      current_order--;
> +      } while (current_order >= order);
>

Will try it out, thanks.


-- 
Mel Gorman
Part-time Phd Student                          Java Applications Developer
University of Limerick                         IBM Dublin Software Lab
-
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/