Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19

[Mel Gorman]

On Tue, 1 Nov 2005, Mel Gorman wrote:

> On Tue, 1 Nov 2005, Dave Hansen wrote:
>
> > On Tue, 2005-11-01 at 07:25 -0800, Martin J. Bligh wrote:
> > > > I really don't think we *want* to say we support higher order allocations
> > > > absolutely robustly, nor do we want people using them if possible. Because
> > > > we don't. Even with your patches.
> > > >
> > > > Ingo also brought up this point at Ottawa.
> > >
> > > Some of the driver issues can be fixed by scatter-gather DMA *if* the
> > > h/w supports it. But what exactly do you propose to do about kernel
> > > stacks, etc? By the time you've fixed all the individual usages of it,
> > > frankly, it would be easier to provide a generic mechanism to fix the
> > > problem ...
> >
> > That generic mechanism is the kernel virtual remapping.  However, it has
> > a runtime performance cost, which is increased TLB footprint inside the
> > kernel, and a more costly implementation of __pa() and __va().
> >
> > I'll admit, I'm biased toward partial solutions without runtime cost
> > before we start incurring constant cost across the entire kernel,
> > especially when those partial solutions have other potential in-kernel
> > users.
>
> To give an idea of the increased TLB footprint, I ran an aim9 test with
> cpu_has_pse disabled in include/arch-i386/cpufeature.h to force the use
> of small pages for the physical memory mappings.
>
> This is the -clean results
>
>                     clean  clean-nopse
>  1 creat-clo      16006.00   15294.90    -711.10 -4.44% File Creations and Closes/second
>  2 page_test     117515.83  118677.11    1161.28  0.99% System Allocations & Pages/second
>  3 brk_test      440289.81  436042.64   -4247.17 -0.96% System Memory Allocations/second
>  4 jmp_test     4179466.67 4173266.67   -6200.00 -0.15% Non-local gotos/second
>  5 signal_test    80803.20   78286.95   -2516.25 -3.11% Signal Traps/second
>  6 exec_test         61.75      60.45      -1.30 -2.11% Program Loads/second
>  7 fork_test       1327.01    1318.11      -8.90 -0.67% Task Creations/second
>  8 link_test       5531.53    5406.60    -124.93 -2.26% Link/Unlink Pairs/second
>
> This is what mbuddy-v19 with and without pse looks like
>
>                  mbuddy-v19 mbuddy-v19-nopse
>  1 creat-clo      15889.41   15328.22    -561.19 -3.53% File Creations and Closes/second
>  2 page_test     117082.15  116892.70    -189.45 -0.16% System Allocations & Pages/second
>  3 brk_test      437887.37  432716.97   -5170.40 -1.18% System Memory Allocations/second
>  4 jmp_test     4179950.00 4176087.32   -3862.68 -0.09% Non-local gotos/second
>  5 signal_test    85335.78   78553.57   -6782.21 -7.95% Signal Traps/second
>  6 exec_test         61.92      60.61      -1.31 -2.12% Program Loads/second
>  7 fork_test       1342.21    1292.26     -49.95 -3.72% Task Creations/second
>  8 link_test       5555.55    5412.90    -142.65 -2.57% Link/Unlink Pairs/second
>

I forgot to include the comparison between -clean and -mbuddy-v19-nopse

                  clean     mbuddy-v19-nopse
 1 creat-clo      16006.00   15328.22    -677.78 -4.23% File Creations and Closes/second
 2 page_test     117515.83  116892.70    -623.13 -0.53% System Allocations & Pages/second
 3 brk_test      440289.81  432716.97   -7572.84 -1.72% System Memory Allocations/second
 4 jmp_test     4179466.67 4176087.32   -3379.35 -0.08% Non-local gotos/second
 5 signal_test    80803.20   78553.57   -2249.63 -2.78% Signal Traps/second
 6 exec_test         61.75      60.61      -1.14 -1.85% Program Loads/second
 7 fork_test       1327.01    1292.26     -34.75 -2.62% Task Creations/second
 8 link_test       5531.53    5412.90    -118.63 -2.14% Link/Unlink Pairs/second

-- 
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/