|Hi Jeremy,
|One quick comment for now below.
|I ran into a problem testing this on my Seattle board, and needed the fix
|below.
|> - } while (pte++, addr += PAGE_SIZE, addr != end);
|> + next = min(end, (addr + CONT_SIZE) & CONT_MASK);
|> + if (((addr | next |
Hi Jeremy,
One quick comment for now below.
I ran into a problem testing this on my Seattle board, and needed the fix below.
Cheers,
--
Steve
On 16 September 2015 at 20:03, Jeremy Linton wrote:
> With 64k pages, the next larger segment size is 512M. The linux
> kernel also uses different
|Hi Jeremy,
|One quick comment for now below.
|I ran into a problem testing this on my Seattle board, and needed the fix
|below.
|> - } while (pte++, addr += PAGE_SIZE, addr != end);
|> + next = min(end, (addr + CONT_SIZE) & CONT_MASK);
|> + if (((addr | next |
Hi Jeremy,
One quick comment for now below.
I ran into a problem testing this on my Seattle board, and needed the fix below.
Cheers,
--
Steve
On 16 September 2015 at 20:03, Jeremy Linton wrote:
> With 64k pages, the next larger segment size is 512M. The linux
> kernel
With 64k pages, the next larger segment size is 512M. The linux
kernel also uses different protection flags to cover its code and data.
Because of this requirement, the vast majority of the kernel code and
data structures end up being mapped with 64k pages instead of the larger
pages common with a
With 64k pages, the next larger segment size is 512M. The linux
kernel also uses different protection flags to cover its code and data.
Because of this requirement, the vast majority of the kernel code and
data structures end up being mapped with 64k pages instead of the larger
pages common with a
6 matches
Mail list logo