Date: Tue, 28 Feb 2012 15:01:00 -0800 From: Artem Belevich <art@freebsd.org> To: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> Cc: freebsd-hackers@freebsd.org, Grzegorz Kulewski <grzegorz@kulewski.pl>, Andriy Gapon <avg@freebsd.org> Subject: Re: improving VM - questions Message-ID: <CAFqOu6gJp1wA_p9ycXnyx4_YDLm6zvXZC50j=UEaqpmvn70M_A@mail.gmail.com> In-Reply-To: <alpine.BSF.2.00.1202282205350.32088@wojtek.tensor.gdynia.pl> References: <alpine.BSF.2.00.1202251630560.1436@wojtek.tensor.gdynia.pl> <4F4C0726.6010804@FreeBSD.org> <alpine.BSF.2.00.1202281043170.1739@wojtek.tensor.gdynia.pl> <4F4CAAC1.9060908@FreeBSD.org> <CAFqOu6hy9S5PHcff4YnoMow5%2BpNT%2Bs_7PXLq%2B1%2BHuiBrW%2BG3yQ@mail.gmail.com> <alpine.BSF.2.00.1202282205350.32088@wojtek.tensor.gdynia.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 28, 2012 at 1:06 PM, Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> wrote: >>>> right. but still 32 pages is 128kB, but i see 64kB I/Os in systat/vmst= at >>> >>> Right, but the comment says to not define MAX_PAGEOUT_CLUSTER to a valu= e greater >>> than 32, but you did that. =A0So all bets could be off unless you exami= ned the >>> code and know exactly what should happen in this case. >> >> I suspect it might be DFLTPHYS that splits disk i/o into 64K blocks on >> the driver level. > can i increase DFLTPHYS as well as i did with MAXPHYS without problems? Sorry, I don't have definitive answer to that. This old post has some related info: http://lists.freebsd.org/pipermail/freebsd-performance/2008-February/003311= .html Even older thread on freebsd-arch also described some concerns: http://lists.freebsd.org/pipermail/freebsd-arch/2004-January/001590.html I don't know whether the stuff above still applies to FreeBSD as it is now: --Artem
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFqOu6gJp1wA_p9ycXnyx4_YDLm6zvXZC50j=UEaqpmvn70M_A>