Re: mmap implementation advice needed.

(Should this be moved to somewhere VAX-specific, maybe?) > The problem was/is (if I understood it right), that someone can mmap > more than 1G, and that will never be possible to map on the VAX. Well...close. > The P0 space is only 1G, and the same is true for the P1 space. But > P0 and P1 is

Re: mmap implementation advice needed.

On 2018-03-30 22:31, Joerg Sonnenberger wrote: On Fri, Mar 30, 2018 at 04:22:29PM -0400, Mouse wrote: And I (and ragge, I think it was) misspoke. It doesn't quite require 128K of contiguous physical space. It needs two 64K blocks of physically contiguous space, both within the block that maps

Re: mmap implementation advice needed.

Den 2018-03-30 kl. 22:31, skrev Joerg Sonnenberger: On Fri, Mar 30, 2018 at 04:22:29PM -0400, Mouse wrote: And I (and ragge, I think it was) misspoke. It doesn't quite require 128K of contiguous physical space. It needs two 64K blocks of physically contiguous space, both within the block that

Re: mmap implementation advice needed.

Den 2018-03-30 kl. 20:43, skrev matthew green: A resource limit for mmap in total would solve the problem though. RLIMIT_AS? you'll have to add support to set it in MD code, but eg. these lines should help. 465:uvm_init_limits(struct proc *p) [..] 479:p->p_rlimit[RLIMIT_AS].rlim_cur =

Re: mmap implementation advice needed.

On Fri, Mar 30, 2018 at 04:22:29PM -0400, Mouse wrote: > And I (and ragge, I think it was) misspoke. It doesn't quite require > 128K of contiguous physical space. It needs two 64K blocks of > physically contiguous space, both within the block that maps system > space. (Nothing says that P0 PTEs

Re: mmap implementation advice needed.

>> It takes 4 bytes of PTE to map 512 bytes of VA. (The VAX uses the >> small, by today's standards, page size of 512 bytes.) So 2G of >> userland space requires 16M of PTEs. Those PTEs must be in system >> virtual space. And that 16M of system virtual space requires 128K >> of PTEs to map,

re: mmap implementation advice needed.

> A resource limit for mmap in total would solve the problem though. RLIMIT_AS? you'll have to add support to set it in MD code, but eg. these lines should help. 465:uvm_init_limits(struct proc *p) [..] 479:p->p_rlimit[RLIMIT_AS].rlim_cur = RLIM_INFINITY; 480:

Re: mmap implementation advice needed.

On Fri, Mar 30, 2018 at 01:10:37PM -0400, Mouse wrote: > It takes 4 bytes of PTE to map 512 bytes of VA. (The VAX uses the > small, by today's standards, page size of 512 bytes.) So 2G of > userland space requires 16M of PTEs. Those PTEs must be in system > virtual space. And that 16M of

Re: mmap implementation advice needed.

>> Notes about vax memory management if someone is wondering: >> - 2 areas (P0 and P1) of size 1G each, P0 grows from bottom, P1 >> grows from top (intended for stack). (Plus, though only slightly relevant to userland mmap, system area (1G) and reserved area (1G). P0 space is

Re: mmap implementation advice needed.

On Fri, Mar 30, 2018 at 11:33:48AM +0200, Anders Magnusson wrote: > Notes about vax memory management if someone is wondering: > - 2 areas (P0 and P1) of size 1G each, P0 grows from bottom, P1 grows from > top (intended for stack). AFAICT, VAX uses a max userland address of 2G, so what exactly is

Re: mmap implementation advice needed.

Den 2018-03-30 kl. 16:46, skrev Christos Zoulas: In article <1ce8eac5-3639-aec1-0e0c-fe857f49b...@ludd.ltu.se>, Anders Magnusson wrote: Hi tech-kern, I'm trying to solve PR#28379 and ran into a problem and I don't really understand how it is supposed to work: If a process

Re: mmap implementation advice needed.

In article <1ce8eac5-3639-aec1-0e0c-fe857f49b...@ludd.ltu.se>, Anders Magnusson wrote: >Hi tech-kern, > >I'm trying to solve PR#28379 and ran into a problem and I don't really >understand how it is supposed to work: >If a process tries to mmap for example a file with a length