Date: Wed, 9 Jun 2010 11:20:22 +0530 From: "Jayachandran C." <c.jayachandran@gmail.com> To: Alan Cox <alc@cs.rice.edu> Cc: Kostik Belousov <kostikbel@gmail.com>, "Jayachandran C." <jchandra@freebsd.org>, mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips Message-ID: <AANLkTimWh77REpi3ZD0BOihZit5qKNYNbtAx5PWQRYBX@mail.gmail.com> In-Reply-To: <AANLkTinzIUOykgwtHlJ2vDwYS9as3ha_BYiy_qRd5h2Q@mail.gmail.com> References: <AANLkTimIa3jmBPMhWIOcY6DenGpZ2ZYmqwDTWspVx0-u@mail.gmail.com> <AANLkTil2gE1niUWCHnsTlQvibhxBh7QYwD0TTWo0rj5c@mail.gmail.com> <AANLkTinA2D5iTDGPbflHVzLyAZW-ZewjJkUWWL8FVskr@mail.gmail.com> <4C07E07B.9060802@cs.rice.edu> <AANLkTimjyPc_AXKP1yaJaF1BN7CAGBeNikVzcp9OCb4P@mail.gmail.com> <4C09345F.9040300@cs.rice.edu> <AANLkTinmFOZY3OlaoKStxlNIRBt2G2I4ILkQ1P0CjozG@mail.gmail.com> <4C0D2BEA.6060103@cs.rice.edu> <AANLkTikZxx_30H9geHvZYkYd0sE-wiuZljEd0PAi14ca@mail.gmail.com> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> <AANLkTilBxdXxXrWC1cAT0wX9ubmFrvaAdk4feG6PwDYQ@mail.gmail.com> <4C0DE424.9080601@cs.rice.edu> <AANLkTinzIUOykgwtHlJ2vDwYS9as3ha_BYiy_qRd5h2Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 9, 2010 at 3:01 AM, Jayachandran C. <c.jayachandran@gmail.com> wrote: > On Tue, Jun 8, 2010 at 12:03 PM, Alan Cox <alc@cs.rice.edu> wrote: >> >> VM_FREEPOOL_DIRECT is used by at least amd64 and ia64 for page table pag= es >> and small kernel memory allocations. =A0Unlike mips, these machines don'= t have >> MMU support for a direct map. =A0Their direct maps are just a range of >> mappings in the regular (kernel) page table. =A0So, unlike mips, accesse= s >> through their direct map may still miss in the TLB and require a page ta= ble >> walk. =A0VM_FREEPOOL_* is a way to increase the physical locality (or >> clustering) of page allocations, so that, for example, page table page >> accesses by the pmap on amd64 are less likely to miss in the TLB. =A0How= ever, >> it doesn't place a hard restriction on the range of physical addresses t= hat >> will be used, which you need for mips. >> >> The impact of this clustering can be significant. =A0For example, on amd= 64 we >> use 2MB page mappings to implement the direct map. =A0However, old Opter= ons >> only had 8 data TLB entries for 2MB page mappings. =A0For a uniprocessor >> kernel running on such an Opteron, I measured an 18% reduction in system >> time during a buildworld with the introduction of VM_FREEPOOL_DIRECT. = =A0(See >> the commit logs for vm/vm_phys.c and the comment that precedes the >> VM_NFREEORDER definition on amd64.) >> >> Until such time as superpage support is ported to mips from the amd64/i3= 86 >> pmaps, I don't think there is a point in having more than one VM_FREEPOO= L_* >> on mips. =A0And then, the point would be to reduce fragmentation of the >> physical memory that could be caused by small allocations, such as page >> table pages. > > Thanks for the detailed explanation. > > Also, after looking at the code again, =A0I think vm_phys_alloc_contig() > can optimized not to look into segments which lie outside the area of > interest. The patch is: [...] > This change, along with the vmparam.h changes for HIGHMEM, I think we > should be able to use =A0vm_phys_alloc_contig() for page table pages (or > have I again missed something fundamental?). That patch was obviously wrong - many segments can map to a freelist as the comment right above my change noted. But the idea of eliminating freelists for which all the segments are outside (low,high) may still be useful, will look at this some more. JC.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimWh77REpi3ZD0BOihZit5qKNYNbtAx5PWQRYBX>