Date: Wed, 10 Apr 2013 14:42:18 -0400 (EDT) From: Benjamin Kaduk <kaduk@MIT.EDU> To: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> Cc: freebsd-hackers@freebsd.org, Sebastian Feld <sebastian.n.feld@gmail.com> Subject: Re: Multiple page size support on FreeBSD? Message-ID: <alpine.GSO.1.10.1304101438500.9389@multics.mit.edu> In-Reply-To: <alpine.BSF.2.00.1304101947470.19441@wojtek.tensor.gdynia.pl> References: <CAHnbEGJuo9Jvskxaog0xLVM_LOse695b4E3fKae7YufOAVZuBg@mail.gmail.com> <alpine.GSO.1.10.1304072319300.9389@multics.mit.edu> <alpine.BSF.2.00.1304081238580.6013@wojtek.tensor.gdynia.pl> <201304101006.13960.jhb@freebsd.org> <alpine.BSF.2.00.1304101947470.19441@wojtek.tensor.gdynia.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 10 Apr 2013, Wojciech Puchar wrote: >> How do your tests work? Do you examine PTEs directly to check for >> superpages >> or are you relying on the vm.pmap.pde sysctls? > > the later. > > anyway - algorithm described on list - that heuristics detects consecutive > page access doesn't really help the urgent case - RANDOM access to large > amount of memory. The algorithm is not a heuristic based on consecutive accesses, promotion occurs when the entire superpage's worth of memory has actually been accessed. If I remember correctly, the performance gain from superpages was only a few percent, so spending more time trying to decide when to use them would make the algorithm a net wash. You should really watch the talk I linked to if you're interested, it was quite interesting. > sequential access will get minimal improvement. > > IMHO the only way that really make sens is to add options to madvise to give > kernel information about usage. Maybe. -Ben Kaduk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.1.10.1304101438500.9389>