> On Sun, Mar 23, 2014 at 20:10, Miod Vallat wrote:
>
> > Except that 1. this is ugly unless you express the values in hex, as
> > noone can spot these are multiples of 4096 in decimal, and 2. I think it
> > is more important to make clear that nback == nforw - 1 (or + 1 in the
> > SEQ case), rega
On Sun, Mar 23, 2014 at 20:10, Miod Vallat wrote:
> Except that 1. this is ugly unless you express the values in hex, as
> noone can spot these are multiples of 4096 in decimal, and 2. I think it
> is more important to make clear that nback == nforw - 1 (or + 1 in the
> SEQ case), regardless of th
> These calculations strike me as weird. Also, I think there's a bug.
> nback should always be the -1 value, right? Oh, wait, it was like
> that. Even stranger.
I think the nback = 8 nforw = 7 was a bug, to begin with, but this diff
attempts to first reach a status quo, for 4KB page size platforms
On Sun, Mar 23, 2014 at 19:45, Miod Vallat wrote:
> The current logic is borrowed from FreeBSD, about 15 years ago, and goes
> like this:
> - for MADV_RANDOM areas, do not try to fault any other page.
> - for MADV_NORMAL areas, try to fault the 3 preceding pages and the 4
> following pages.
> - f
Our vm system has some optimization logic which, when servicing a page
fault, attempts to fault the neighbouring pages, if this is expected to
speed things up on the long term.
That logic is controlled by the madvise() state of the memory area being
faulted in, with the defaults being that device
