0 0 0 --- 0 0 0x0 NCOW NNC not-wired none -
0x7ffe 0x8000 32 0 0xff002dd125e8 rwx 1 0 0x3100 NCOW NNC
wired default -
--- On Fri, 4/13/12, Konstantin Belousov wrote:
From: Konstantin Belousov
Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN
To: "Sushanth Rai&qu
On Wed, Apr 18, 2012 at 04:37:45PM -0700, Sushanth Rai wrote:
> Wiring entire address space seems to have interesting side effect. The
> libc memory allocator calls madvise() to free the dirty unused pages,
> which does nothing when the pages are wired. The allocator unmaps only
> when entire chunk
which cannot
reclaimed even when the system is under memory pressure.
Sushanth
--- On Mon, 4/16/12, Sushanth Rai wrote:
> From: Sushanth Rai
> Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN
> To: "Konstantin Belousov"
> Cc: a...@freebsd.org, freebsd-hack
Many thanks. I verified the patch you provided and it works fine.
Sushanth
> Oh, I see. The problem is the VM_MAP_WIRE_NOHOLES flag.
> Since we
> map only the initial stack fragment even for the
> MCL_WIREFUTURE maps,
> there is a hole in the stack region.
>
> In fact, for MCL_WIREFUTURE, we pr
32 0 0xffffff002dd125e8 rwx 1 0 0x3100 NCOW NNC
> wired default -
>
> --- On Fri, 4/13/12, Konstantin Belousov wrote:
>
> > From: Konstantin Belousov
> > Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN
> > To: "Sushanth Rai"
> > Cc: freeb
sleep(5);
}
}
--- On Fri, 4/13/12, Sushanth Rai wrote:
> From: Sushanth Rai
> Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN
> To: "Konstantin Belousov"
> Cc: freebsd-hackers@freebsd.org
> Date: Friday, April 13, 2012, 11:37 AM
>
W NNC
wired default -
--- On Fri, 4/13/12, Konstantin Belousov wrote:
> From: Konstantin Belousov
> Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN
> To: "Sushanth Rai"
> Cc: freebsd-hackers@freebsd.org
> Date: Friday, April 13, 2012, 1:11 AM
> O
On Thu, Apr 12, 2012 at 08:10:26PM -0700, Sushanth Rai wrote:
> >
> > Then it should be fixed in r190885.
> >
>
> Thanks. That works like a charm.
>
> mlockall() mostly works now. There is still a, issue in wiring the stacks of
> multithreaded program when the program uses default stack alloc
>
> Then it should be fixed in r190885.
>
Thanks. That works like a charm.
mlockall() mostly works now. There is still a, issue in wiring the stacks of
multithreaded program when the program uses default stack allocation scheme.
Thread library allocates stack for each thread by calling mmap(
On Tue, Apr 10, 2012 at 06:33:44PM -0700, Sushanth Rai wrote:
>
> > > I don't know if that has anything to do with failure.
> > The snippet of code that returns failure in vm_fault() is
> > the following:
> > >
> > > if (fs.pindex >= fs.object->size) {
> > >
> > unlock_and_deallocate(&fs);
> > I don't know if that has anything to do with failure.
> The snippet of code that returns failure in vm_fault() is
> the following:
> >
> > if (fs.pindex >= fs.object->size) {
> >
> unlock_and_deallocate(&fs);
> > return
> (KERN_PROTECTION_FAILURE);
> > }
> >
> > Any help would be
On Mon, Apr 09, 2012 at 07:37:11PM -0700, Sushanth Rai wrote:
> Hello,
>
> I have a simple program that links with the math library. The only thing that
> program does is to call mlockall(MCL_CURRENT | MCL_FUTURE). This call to
> mlockall fails with EAGAIN. I figured out that kernel vm_fault() i
Hello,
I have a simple program that links with the math library. The only thing that
program does is to call mlockall(MCL_CURRENT | MCL_FUTURE). This call to
mlockall fails with EAGAIN. I figured out that kernel vm_fault() is returning
KERN_PROTECTION_FAILURE when it tries to fault-in the mmap'
13 matches
Mail list logo
