On Wed, 25 May 2005, Joel Schopp wrote:

quoted

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.

quoted

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.

quoted

+/*
+ * 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?

quoted

+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.

quoted

+    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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>