Just in case the attachment doesn't come through. Here is the program:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/time.h>
#include <strings.h>
#include <pthread.h>
#include <unistd.h>
#include <errno.h>
#include <sys/mman.h>
void * thr_func(void *);
#define MAX_THREADS 5
main()
{
int i;
int thread_num[MAX_THREADS];
pthread_t tid[MAX_THREADS];
if (mlockall(MCL_CURRENT|MCL_FUTURE) < 0) {
perror("Failure to lock address space");
exit(1);
}
for (i=0; i < MAX_THREADS; i++) {
thread_num[i] = i+1;
if (pthread_create(&tid[i], NULL, thr_func,
&thread_num[i]) != 0) {
perror("thread creation failed");
exit(1);
}
}
for (i=0; i < MAX_THREADS; i++) {
if (pthread_join(tid[i], NULL) != 0) {
perror("pthread_join failed\n");
exit(1);
}
}
}
void * thr_func(void *arg)
{
int *tnum = (int *)arg;
printf("Thead %d going to sleep\n", *tnum);
while(1) {
sleep(5);
}
}
--- On Fri, 4/13/12, Sushanth Rai <sushanth_...@yahoo.com> wrote:
> From: Sushanth Rai <sushanth_...@yahoo.com>
> Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN
> To: "Konstantin Belousov" <kostik...@gmail.com>
> Cc: freebsd-hackers@freebsd.org
> Date: Friday, April 13, 2012, 11:37 AM
> I've attached the simple program that
> creates 5 threads. Following is the o/p of
> /proc/<pid>/map when this program is running. Note
> that I modified
> sys/fs/procfs/procfs_map.c to print whether a region is
> wired. As you can see from this o/p, none of stack areas get
> wired.
>
> 0x400000 0x401000 1 0 0xffffff002d943bd0 r-x 1 0 0x1000 COW
> NC wired vnode /var/tmp/thread1
> 0x500000 0x501000 1 0 0xffffff002dd13e58 rw- 2 0 0x3100 NCOW
> NNC wired default -
> 0x501000 0x600000 255 0 0xffffff002dd13e58 rwx 2 0 0x3100
> NCOW NNC wired default -
> 0x800500000 0x800526000 38 0 0xffffff0025574000 r-x 192 46
> 0x1004 COW NC wired vnode /libexec/ld-elf.so.1
> 0x800526000 0x800537000 17 0 0xffffff002d9f81b0 rw- 1 0
> 0x3100 NCOW NNC wired default -
> 0x800626000 0x80062d000 7 0 0xffffff002dd13bd0 rw- 1 0
> 0x3100 COW NNC wired vnode /libexec/ld-elf.so.1
> 0x80062d000 0x800633000 6 0 0xffffff002dd145e8 rw- 1 0
> 0x3100 NCOW NNC wired default -
> 0x800633000 0x800645000 18 0 0xffffff00256d71b0 r-x 63 42
> 0x4 COW NC wired vnode /lib/libthr.so.3
> 0x800645000 0x800646000 1 0 0xffffff002d975510 r-x 1 0
> 0x3100 COW NNC wired vnode /lib/libthr.so.3
> 0x800646000 0x800746000 0 0 0xffffff002dc5cca8 --- 4 0
> 0x3100 NCOW NNC not-wired default -
> 0x800746000 0x80074a000 4 0 0xffffff002572a288 rw- 1 0
> 0x3100 COW NNC wired vnode /lib/libthr.so.3
> 0x80074a000 0x80074c000 2 0 0xffffff002dc5cca8 rw- 4 0
> 0x3100 NCOW NNC wired default -
> 0x80074c000 0x80083e000 242 0 0xffffff001cd226c0 r-x 238 92
> 0x1004 COW NC wired vnode /lib/libc.so.7
> 0x80083e000 0x80083f000 1 0 0xffffff002dd12000 r-x 1 0
> 0x3100 COW NNC wired vnode /lib/libc.so.7
> 0x80083f000 0x80093e000 0 0 0xffffff002dc5cca8 --- 4 0
> 0x3100 NCOW NNC not-wired default -
> 0x80093e000 0x80095d000 31 0 0xffffff002dddc360 rw- 1 0
> 0x3100 COW NNC wired vnode /lib/libc.so.7
> 0x80095d000 0x800974000 23 0 0xffffff002dc5cca8 rw- 4 0
> 0x3100 NCOW NNC wired default -
> 0x800a00000 0x800b00000 256 0 0xffffff002dbd1798 rw- 1 0
> 0x3100 NCOW NNC wired default -
> 0x800b00000 0x800c00000 256 0 0xffffff002dd14948 rw- 1 0
> 0x3100 NCOW NNC wired default -
> 0x7fffff3db000 0x7fffff3fb000 1 0 0xffffff002dbb4360 rw- 1 0
> 0x3100 NCOW NNC not-wired default -
> 0x7fffff5dc000 0x7fffff5fc000 1 0 0xffffff002dc66af8 rw- 1 0
> 0x3100 NCOW NNC not-wired default -
> 0x7fffff7dd000 0x7fffff7fd000 1 0 0xffffff002dbea438 rw- 1 0
> 0x3100 NCOW NNC not-wired default -
> 0x7fffff9de000 0x7fffff9fe000 1 0 0xffffff002dd7fd80 rw- 1 0
> 0x3100 NCOW NNC not-wired default -
> 0x7fffffbdf000 0x7fffffbff000 1 0 0xffffff002dbe9438 rw- 1 0
> 0x3100 NCOW NNC not-wired default -
> 0x7fffffbff000 0x7fffffc00000 0 0 0 --- 0 0 0x0 NCOW NNC
> not-wired none -
> 0x7ffffffe0000 0x800000000000 32 0 0xffffff002dd125e8 rwx 1
> 0 0x3100 NCOW NNC wired default -
>
> --- On Fri, 4/13/12, Konstantin Belousov <kostik...@gmail.com>
> wrote:
>
> > From: Konstantin Belousov <kostik...@gmail.com>
> > Subject: Re: mlockall() on freebsd 7.2 + amd64 returns
> EAGAIN
> > To: "Sushanth Rai" <sushanth_...@yahoo.com>
> > Cc: freebsd-hackers@freebsd.org
> > Date: Friday, April 13, 2012, 1:11 AM
> > 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 allocation scheme. Thread library
> > allocates stack for each thread by calling mmap() and
> > sending address and size to be mapped. The kernel
> adjusts
> > the start address to sgrowsz in vm_map_stack() and
> > maps at the adjusted address. But the subsequent wiring
> is
> > done using the original address, which fails.
> > >
> > Can you, please provide stand-alone example which
> > demostrates the issue ?
> > I suspect this should have not changed in HEAD.
> >
> -----Inline Attachment Follows-----
>
> _______________________________________________
> freebsd-hackers@freebsd.org
> mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
