lkml.org 
[lkml]   [2005]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Avoiding external fragmentation with a placement policy Version 11
On Wed, 25 May 2005, Joel Schopp wrote:

> > Changelog since V10
> >
> > o Important - All allocation types now use per-cpu caches like the standard
> > allocator. Older versions may have trouble with large numbers of
> > processors
>
> Do you have a new set of benchmarks we could see? The ones you had for v10
> were pretty useful.
>

Only what I've posted as part of the patch. I cannot benchmark the
scalability on large numbers of processors as I lack such a machine. I am
*guessing* that the inability of previous patch versions to use per-cpu
caches for kernel allocations would have hurt, but I do not know for a
fact.

> > o Removed all the additional buddy allocator statistic code
>
> Is there a separate patch for the statistic code or is it no longer being
> maintained?
>

It's still being maintained, I didn't post it because I didn't think
people were interested and I am happy to keep the stats patch as part of
VMRegress. The current version of the statistics patch is attached this
mail. It comes with a noticeable performance penalty when enabled.

> > +/*
> > + * Shared per-cpu lists would cause fragmentation over time
> > + * The pcpu_list is to keep kernel and userrclm allocations
> > + * apart while still allowing all allocation types to have
> > + * per-cpu lists
> > + */
>
> Why are kernel nonreclaimable and kernel reclaimable joined here? I'm not
> saying you are wrong, I'm just ignorant and need some education.
>

Right now, the KernRclm areas tend to free up in large blocks over time,
but there is no way of forcing it so we rarely get the MAX_ORDER-1 sized
blocks from the kernel areas. The per-cpu caches pollute areas very slowly
but are not very noticable in the kernrclm areas. As I don't expect to get
the interesting large blocks fre ein the kernel areas, and this is a
critical path, I decided to let the per-cpu lists share the kernel lists.

When hotplug comes into play, or we have a mechanism for force-reclaiming
the KernRclm areas, this will need to be revisited.

Does this make sense?

> > +struct pcpu_list {
> > + int count;
> > + struct list_head list;
> > +} ____cacheline_aligned_in_smp;
> > +
> > struct per_cpu_pages {
> > - int count; /* number of pages in the list */
> > + struct pcpu_list pcpu_list[2]; /* 0: kernel 1: user */
> > int low;/* low watermark, refill needed */
> > int high; /* high watermark, emptying needed */
> > int batch; /* chunk size for buddy add/remove */
> > - struct list_head list; /* the list of pages */
> > };
> >
>
> Instead of defining 0 and 1 in a comment why not use a #define?
>

We could, and in an unreleased version, it was a #define. I used the 0 and
1 to look similar to how hot/cold page lists are managed and I wanted
things to look familiar.

> > + pcp->pcpu_list[0].count = 0;
> > + pcp->pcpu_list[1].count = 0;
>
> The #define would make code like this look more readable.
>

I'll release a verion on Monday against the latest rc5 kernel with a
#define instead. Probably something like PCPU_KERNEL and PCPU_USER

--
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/

\
 
 \ /
  Last update: 2005-05-26 14:40    [W:0.051 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site