Messages in this thread | | | Date | Thu, 8 Apr 2004 12:25:43 -0700 | From | Andrew Morton <> | Subject | Re: NUMA API for Linux |
| |
Hugh Dickins <hugh@veritas.com> wrote: > > On Wed, 7 Apr 2004, Andrew Morton wrote: > > > > Your patch takes the CONFIG_NUMA vma from 64 bytes to 68. It would be nice > > to pull those 4 bytes back somehow. > > How significant is this vma size issue?
For some workloads/machines it will simply cause an approximately-proportional reduction in the size of the workload which we can handle.
ie: there are some (oracle) workloads where the kernel craps out due to lowmem vma exhaustion. If they're now using remap_file_pages() for this then it may not be a problem any more. Ingo would know better than I.
> anon_vma objrmap will add 20 bytes to each vma (on 32-bit arches): > 8 for prio_tree, 12 for anon_vma linkage in vma, > sometimes another 12 for the anon_vma head itself. > > anonmm objrmap adds just the 8 bytes for prio_tree, > remaining overhead 28 bytes per mm. > > Seems hard on Andi to begrudge him 4.
- 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/
| |