On 12.10.2013, at 18:14, Konstantin Belousov wrote:
>>
>> First I tried with some swap space configured. The OS started to swap out
>> my process after it reached about 20GB which is also not what I expected:
>> what is the reason to swap out regions of read-onl
target cannot be reached.
>
>
> First I tried with some swap space configured. The OS started to swap out my
> process after it reached about 20GB which is also not what I expected: what
> is the reason to swap out regions of read-only mmap()ed files? Is it the
> expect
the reason to swap out regions of read-only mmap()ed files? Is it the expected
behaviour?
>
> Below is the prototype patch, against HEAD. It is not applicable to
> stable, please use HEAD kernel for test.
Thanks, I will test the patch soon and report the results.
___
On Fri, Oct 11, 2013 at 09:57:24AM +0400, Dmitry Sivachenko wrote:
>
> On 11.10.2013, at 9:17, Konstantin Belousov wrote:
>
> > On Wed, Oct 09, 2013 at 03:42:27PM +0400, Dmitry Sivachenko wrote:
> >> Hello!
> >>
> >> I have a program which mmap()s
On 11.10.2013, at 9:17, Konstantin Belousov wrote:
> On Wed, Oct 09, 2013 at 03:42:27PM +0400, Dmitry Sivachenko wrote:
>> Hello!
>>
>> I have a program which mmap()s a lot of large files (total size more that
>> RAM and I have no swap), but it needs only sma
On Wed, Oct 09, 2013 at 03:42:27PM +0400, Dmitry Sivachenko wrote:
> Hello!
>
> I have a program which mmap()s a lot of large files (total size more that RAM
> and I have no swap), but it needs only small parts of that files at a time.
>
> My understanding is that when using
On Wed, 9 Oct 2013 15:42:27 +0400
Dmitry Sivachenko wrote:
> Hello!
>
> I have a program which mmap()s a lot of large files (total size more
> that RAM and I have no swap), but it needs only small parts of that
> files at a time.
>
> My understanding is that when using mm
Hello!
I have a program which mmap()s a lot of large files (total size more that RAM
and I have no swap), but it needs only small parts of that files at a time.
My understanding is that when using mmap when I access some memory region OS
reads the relevant portion of that file from disk and
On Tue, Sep 17, 2013 at 07:01:16PM -0700, Rui Paulo wrote:
> Hi,
>
> I'm trying to figure out why the following fails when compiled on amd64 with
> -m32:
>
> mmap(NULL, 0x7, PROT_READ|PROT_WRITE|PROT_EXEC,
> MAP_ANON|MAP_PRIVATE, -1, 0);
>
> It
Hi,
I'm trying to figure out why the following fails when compiled on amd64 with
-m32:
mmap(NULL, 0x7, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_ANON|MAP_PRIVATE, -1, 0);
It returns EINVAL. I looked around everywhere but I couldn't find where the
EINVAL is coming from.
:53PM +0400, Andrey Zonov wrote:
Hi,
I open the file, then call mmap() on the whole file and get pointer,
then I work with this pointer. I expect that page should be only
once
touched to get it into the memory (disk cache?), but this doesn't
work!
I wrote the test (attached) and ran it for t
open the file, then call mmap() on the whole file and get pointer,
then I work with this pointer. I expect that page should be only
once
touched to get it into the memory (disk cache?), but this doesn't
work!
I wrote the test (attached) and ran it for the 1G file generated
from
/dev/r
at the required address?
> int main()
> {
> unsigned int *addr,*newaddr;
> unsigned long a=134516736,a1;
> unsigned long b=3895296;
> unsigned long flags =6;
> a1=(a&0xffff0000);
> printf("%x\n",(void *)a);
> newaddr=(unsigned int *)mmap((void *)a,b,6,M
igned long a=134516736,a1;
unsigned long b=3895296;
unsigned long flags =6;
a1=(a&0x);
printf("%x\n",(void *)a);
newaddr=(unsigned int *)mmap((void *)a,b,6,MAP_ANONYMOUS|MAP_FIXED,-1,0);
if(newaddr==MAP_FAILED)
printf("mmap failed");
else
printf("sucess %x",n
On 10.04.2012 20:19, Alan Cox wrote:
On 04/09/2012 10:26, John Baldwin wrote:
On Thursday, April 05, 2012 11:54:31 am Alan Cox wrote:
On 04/04/2012 02:17, Konstantin Belousov wrote:
On Tue, Apr 03, 2012 at 11:02:53PM +0400, Andrey Zonov wrote:
Hi,
I open the file, then call mmap() on the
Andrey writes:
> Wired memory: kernel memory and yes, application may get wired memory
> through mlock()/mlockall(), but I haven't seen any real application
> which calls mlock().
Apps with real time considerations may need to lock memory to prevent
having to wait for page/swap.
__
On 04/09/2012 10:26, John Baldwin wrote:
On Thursday, April 05, 2012 11:54:31 am Alan Cox wrote:
On 04/04/2012 02:17, Konstantin Belousov wrote:
On Tue, Apr 03, 2012 at 11:02:53PM +0400, Andrey Zonov wrote:
Hi,
I open the file, then call mmap() on the whole file and get pointer,
then I work
On Thursday, April 05, 2012 11:54:31 am Alan Cox wrote:
> On 04/04/2012 02:17, Konstantin Belousov wrote:
> > On Tue, Apr 03, 2012 at 11:02:53PM +0400, Andrey Zonov wrote:
> >> Hi,
> >>
> >> I open the file, then call mmap() on the whole file and get pointer,
&g
ing:
> >>
> >> Active memory: the memory which is referenced by application. An
> > Assuming the part 'by application' is removed, this sentence is almost
> > right.
> > Any managed mapping of the page participates in the active references.
> >
&g
> >wire their pages as well.
>>
>> Let's talk about that in details.
>>
>> My understanding is the following:
>>
>> Active memory: the memory which is referenced by application. An
> Assuming the part 'by application' is removed, this sentence i
to change:
> >>>>>
> >>>>>pmap_remove_all(mt);
> >>>>>if (mt->dirty != 0)
> >>>>>vm_page_deactivate(mt);
> >>>>>else
> >>>>>vm_page_cache(mt);
> >>>>>
> >>>&
nks Alan! Now it works as I expect!
But I have more questions to you and kib@. They are in my test below.
So, prepare file as earlier, and take information about memory usage
>from top(1). After preparation, but before test:
Mem: 80M Active, 55M Inact, 721M Wired, 215M Buf, 46G Free
First
:53PM +0400, Andrey Zonov wrote:
Hi,
I open the file, then call mmap() on the whole file and get pointer,
then I work with this pointer. I expect that page should be only once
touched to get it into the memory (disk cache?), but this doesn't work!
I wrote the test (attached) and ran it for t
On 04/04/2012 02:17, Konstantin Belousov wrote:
On Tue, Apr 03, 2012 at 11:02:53PM +0400, Andrey Zonov wrote:
Hi,
I open the file, then call mmap() on the whole file and get pointer,
then I work with this pointer. I expect that page should be only once
touched to get it into the memory (disk
, Andrey Zonov wrote:
> >>>>Hi,
> >>>>
> >>>>I open the file, then call mmap() on the whole file and get pointer,
> >>>>then I work with this pointer. I expect that page should be only once
> >>>>touched to get it into the me
t;to:
> >>>
> >>>vm_page_dontneed(mt);
> >>>
> >>
> >>Thanks Alan! Now it works as I expect!
> >>
> >>But I have more questions to you and kib@. They are in my test below.
> >>
> >>So, prepare file as earlier, an
On 05.04.2012 23:54, Andrey Zonov wrote:
On 05.04.2012 23:41, Konstantin Belousov wrote:
You do use UFS, right ?
Yes.
I've run test on ZFS.
Mem: 2645M Active, 363M Inact, 2042M Wired, 1406M Buf, 42G Free
$ ./mmap /mnt/random
Mem: 3669M Active, 363M Inact, 3067M Wired, 1406M Buf
w.
So, prepare file as earlier, and take information about memory usage
from top(1). After preparation, but before test:
Mem: 80M Active, 55M Inact, 721M Wired, 215M Buf, 46G Free
First run:
$ ./mmap /mnt/random
mmap: 1 pass took: 7.462865 (none: 0; res: 262144; super:
0; other: 0)
No supe
gt; >to:
> >
> >vm_page_dontneed(mt);
> >
>
> Thanks Alan! Now it works as I expect!
>
> But I have more questions to you and kib@. They are in my test below.
>
> So, prepare file as earlier, and take information about memory usage
> from top(1). After
test:
Mem: 80M Active, 55M Inact, 721M Wired, 215M Buf, 46G Free
First run:
$ ./mmap /mnt/random
mmap: 1 pass took: 7.462865 (none: 0; res: 262144; super:
0; other: 0)
No super pages after first run, why?..
Mem: 79M Active, 1079M Inact, 722M Wired, 216M Buf, 45G Free
Now the fil
On 04/05/2012 12:31, Konstantin Belousov wrote:
On Thu, Apr 05, 2012 at 10:54:31AM -0500, Alan Cox wrote:
On 04/04/2012 02:17, Konstantin Belousov wrote:
On Tue, Apr 03, 2012 at 11:02:53PM +0400, Andrey Zonov wrote:
Hi,
I open the file, then call mmap() on the whole file and get pointer
On Thu, Apr 05, 2012 at 10:54:31AM -0500, Alan Cox wrote:
> On 04/04/2012 02:17, Konstantin Belousov wrote:
> >On Tue, Apr 03, 2012 at 11:02:53PM +0400, Andrey Zonov wrote:
> >>Hi,
> >>
> >>I open the file, then call mmap() on the whole file and get pointer,
&
satisfied. There are several tests below:
1. With madvise(MADV_RANDOM) I see almost all super pages:
$ ./mmap /mnt/random-1024 5
mmap: 1 pass took: 26.438535 (none: 0; res: 262144; super: 511;
other: 0)
mmap: 2 pass took: 0.187311 (none: 0; res: 262144; super: 511;
other:
On 04/04/2012 02:17, Konstantin Belousov wrote:
On Tue, Apr 03, 2012 at 11:02:53PM +0400, Andrey Zonov wrote:
Hi,
I open the file, then call mmap() on the whole file and get pointer,
then I work with this pointer. I expect that page should be only once
touched to get it into the memory (disk
super pages
but I'm still not satisfied. There are several tests below:
1. With madvise(MADV_RANDOM) I see almost all super pages:
$ ./mmap /mnt/random-1024 5
mmap: 1 pass took: 26.438535 (none: 0; res: 262144; super: 511; other: 0)
mmap: 2 pass took: 0.187311 (none: 0; res: 262144; super: 511
1. With madvise(MADV_RANDOM) I see almost all super pages:
$ ./mmap /mnt/random-1024 5
mmap: 1 pass took: 26.438535 (none: 0; res: 262144; super:
511; other: 0)
mmap: 2 pass took: 0.187311 (none: 0; res: 262144; super:
511; other: 0)
mmap: 3 pass took: 0.184953 (no
On Tue, Apr 03, 2012 at 11:02:53PM +0400, Andrey Zonov wrote:
> Hi,
>
> I open the file, then call mmap() on the whole file and get pointer,
> then I work with this pointer. I expect that page should be only once
> touched to get it into the memory (disk cache?), but this doesn
Hi,
I open the file, then call mmap() on the whole file and get pointer,
then I work with this pointer. I expect that page should be only once
touched to get it into the memory (disk cache?), but this doesn't work!
I wrote the test (attached) and ran it for the 1G file generated from
On Saturday, December 03, 2011 5:37:01 am Filippo Sironi wrote:
> I need to access the memory both from user space and kernel space, I cannot
do that (simply) with an mmap or thread-specific storage if I recall
correctly.
You could allocate a dedicated VM object for each thread's inf
On 12/3/11 2:37 AM, Filippo Sironi wrote:
I need to access the memory both from user space and kernel space, I cannot do
that (simply) with an mmap or thread-specific storage if I recall correctly.
that's how mmap works.. if you give it pages to expose to the user,
you can still access
thout crossing user to kernel and kernel to user
boundaries.
To read and write the memory page I decided to allocate it in kernel space and then
mmap'ing it to user space using a "virtual cdev" as an entry point for user
space threads. The implementation of the mmap I came up with
In message <0011fd6a-e29d-4f67-913c-897ba1b2f...@gmail.com>, Filippo Sironi wri
tes:
>I need to access the memory both from user space and kernel space, I =
>cannot do that (simply) with an mmap or thread-specific storage if I =
>recall correctly.
Have you looked how shm_open(2)
In message , Filippo Sironi wri
tes:
>Ok, that's what I was suspecting.
>Do you have any ideas on how to get the behavior I described in the =
>previous mail?
Why don't you just use mmap(2) ? I couldn't see anything you
couldn't do with it.
There's also supp
In message , Filippo Sironi wri
tes:
>The problem is that when I come =
>back to user space all the threads write in memory page mapped by the =
>first thread that called the mmap leaving their memory pages untouched.
That's how cdev->mmap works, it is global rather than per-t
I need to access the memory both from user space and kernel space, I cannot do
that (simply) with an mmap or thread-specific storage if I recall correctly.
On 03/dic/2011, at 11.00, Poul-Henning Kamp wrote:
> In message , Filippo Sironi
> wri
> tes:
>
> Why don't you j
r space all the threads write in memory page mapped by the =
>> first thread that called the mmap leaving their memory pages untouched.
>
> That's how cdev->mmap works, it is global rather than per-thread.
>
>
> --
> Poul-Henning Kamp | UNIX since Zilo
user
boundaries.
To read and write the memory page I decided to allocate it in kernel space and
then mmap'ing it to user space using a "virtual cdev" as an entry point for
user space threads. The implementation of the mmap I came up with is really
trivial, I basically do:
*paddr
in
>> userland how to force kernel to call pmap_enter_object() which makes
>> SUPERPAGE mapping without promotion. I tried to call mmap() with
>> MAP_PREFAULT_READ without success. I tried to call madvise() with
>> MADV_WILLNEED without success too.
>>
>
> mmap() should c
n. I tried to call mmap() with
MAP_PREFAULT_READ without success. I tried to call madvise() with
MADV_WILLNEED without success too.
mmap() should call pmap_enter_object() if MAP_PREFAULT_READ was
specified. I'm surprised to hear that it's not happening for you.
To make SUPERPAGE m
Hi,
well, I'm working on new port (arm11 mpcore) and pmap_enter_object()
is what I'm debugging rigth now. And I did not find any way in
userland how to force kernel to call pmap_enter_object() which makes
SUPERPAGE mapping without promotion. I tried to call mmap() with
MAP_PREFAULT_RE
. Similarly, mmap(...,
MAP_PREFAULT_READ) on a large, memory resident file may pre-map the
file using superpage mappings.
your options are not described in mmap manpage nor madvise
(MAP_PREFAULT_READ).
when can i find the up to date manpage or description?
A few minutes ago, I merged the
boundary and be contiguous?
Yes. However, if you allocate (or mmap(2)) a large range of virtual
memory, e.g., 10 MB, and the start of that range is not aligned on a
superpage boundary, the virtual memory system can still promote the four
2 MB sized superpages in the middle of that range.
manage large pages, there could be some
benefit in the form of reduced overhead. So, it's on my "to do" list,
but no where near the top of that list.
Alan
Am I correct in remembering that super-pages have to be aligned on the
super-page boundary and be contiguous?
If so, in the
. Similarly, mmap(...,
MAP_PREFAULT_READ) on a large, memory resident file may pre-map the
file using superpage mappings.
your options are not described in mmap manpage nor madvise
(MAP_PREFAULT_READ).
when can i find the up to date manpage or description?
It is documented in mmap(2) on HEAD
ysical pages worth of memory for every superpage
> mapping.
But wouldn't the "conservative" superpages policy make it difficult in
the OPs case to ever get promotions to superpages if he's touching pages
almost randomly?
> Similarly, mmap(..., MAP_PREFAULT_READ) on a la
are created
directly and not by promotion from small page mappings. For example, if a
large executable, such as gcc, is resident in memory, the text segment will
be pre-mapped using superpage mappings, avoiding soft fault and promotion
overhead. Similarly, mmap(..., MAP_PREFAULT_READ) on a
.pmap.pde.mappings counts superpage mappings that are
created directly and not by promotion from small page mappings. For
example, if a large executable, such as gcc, is resident in memory, the
text segment will be pre-mapped using superpage mappings, avoiding soft
fault and promotion o
On Thu, Oct 6, 2011 at 11:01 AM, Kostik Belousov wrote:
> On Thu, Oct 06, 2011 at 04:41:45PM +0200, Wojciech Puchar wrote:
> > i have few questions.
> >
> > 1) suppose i map 1TB of address space as anonymous and touch just one
> > page. how much memory is used to manage this?
> I am not sure how d
You are correct about the page table page. However, a superpage mapping
consumes a single PV entry, in place of 512 or 1024 PV
entries. This winds up saving about three physical pages worth of memory for
every superpage mapping.
does it actually work?
simple test
before (only idle system w
d disk I/O will not be a deciding
factor.
To avoid system calls i just want to mmap tables and indexes. All
semaphores can be done from userspace too, and i already know how to avoid
lock contention well.
Using indexes means doing lots of memory reads from different pages, but
for every pro
On Thu, Oct 06, 2011 at 04:41:45PM +0200, Wojciech Puchar wrote:
> i have few questions.
>
> 1) suppose i map 1TB of address space as anonymous and touch just one
> page. how much memory is used to manage this?
I am not sure how deep the enumeration you want to know, but the first
approximation w
i have few questions.
1) suppose i map 1TB of address space as anonymous and touch just one
page. how much memory is used to manage this?
2) suppose we have 1TB file on disk without holes and 10 processes
mmaps this file to it's address space. are just pages shared or can
pagetables be s
Guys,
if we the following on FreeBSD (pseudo-code):
fd = open(/dev/dsp, O_RDWR);
mmap(PROT_READ, fd);
mmap(PROT_WRITE, fd);
This won't work entirely correctly, right?
I base my question on some observations of how a particular program behaves on
FreeBSD and on the following comment in sy
On Monday 22 March 2010 3:46:53 pm Alexander Best wrote:
> John Baldwin schrieb am 2010-03-22:
> > On Monday 22 March 2010 11:07:43 am Alexander Best wrote:
> > > could somebody please commit this patch? it's been around forever
> > > (2003 or
> > > 2004)
John Baldwin schrieb am 2010-03-22:
> On Monday 22 March 2010 11:07:43 am Alexander Best wrote:
> > could somebody please commit this patch? it's been around forever
> > (2003 or
> > 2004) and fixes mmap so the offset argument is being ignored when
> > MAP_ANON
>
On Monday 22 March 2010 11:07:43 am Alexander Best wrote:
> could somebody please commit this patch? it's been around forever (2003 or
> 2004) and fixes mmap so the offset argument is being ignored when MAP_ANON
is
> defined (just like the mmap(2) manual says). right now the offse
oops. forgot the patch. ;)
--
Alexander Best
Index: sys/vm/vm_mmap.c
===
--- sys/vm/vm_mmap.c(revision 205390)
+++ sys/vm/vm_mmap.c(working copy)
@@ -241,19 +241,23 @@
((prot & (PROT_READ | PROT_WRITE)) !=
could somebody please commit this patch? it's been around forever (2003 or
2004) and fixes mmap so the offset argument is being ignored when MAP_ANON is
defined (just like the mmap(2) manual says). right now the offset argument is
being taken into account although MAP_ANON is set!!!
the
On Fri, 27.11.2009 at 18:22:38 -0800, Maxim Sobolev wrote:
> Crazy idea, perhaps, but has anyone considered wrapping up sbrk(2) into
> mmap(2), so that there is only one memory pool to draw from? Switch to
> 64-bit certainly helps, however there are lot of 32-bit machines hanging
>
2
>sbsize infinity bytes
>vmemoryuse infinity kB
>
> Running ktrace I see:
>
>9154 java CALL
> mmap(0,0x4400,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_NORESERVE|MAP_ANON,0x,0,0)
>9154 java RET mmap
Maxim Sobolev wrote:
Jason Evans wrote:
I would set MAXDSIZ to 0, so that the maximum amount of memory is
available for mapping shared libraries and files, and allocating via
malloc. This may cause problems with a couple of ports that implement
their own memory allocators based on sbrk, but
, and you
reserved 2GiB for DSS. That leaves less than 1GiB available after
shared libraries and whatnot are mapped. If there is more than 1GiB
available, mmap can still fail due to the memory being non-contiguous.
So, are you saying that by allocating 2GB to MAXDSIZ, I limit myself
less than
2GiB for DSS. That leaves less than 1GiB available after
shared libraries and whatnot are mapped. If there is more than 1GiB
available, mmap can still fail due to the memory being non-contiguous.
So, are you saying that by allocating 2GB to MAXDSIZ, I limit myself
less than 1GB left to be
leaves less than 1GiB available after
shared libraries and whatnot are mapped. If there is more than 1GiB
available, mmap can still fail due to the memory being non-contiguous.
Jason,
So, are you saying that by allocating 2GB to MAXDSIZ, I limit myself
less than 1GB left to be allocated via mmap
available after
shared libraries and whatnot are mapped. If there is more than 1GiB
available, mmap can still fail due to the memory being non-contiguous.
Jason
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
2097152 kB
stacksize 65536 kB
coredumpsize infinity kB
memoryuseinfinity kB
memorylocked infinity kB
maxprocesses 5547
openfiles 2
sbsize infinity bytes
vmemoryuse infinity kB
Running ktrace I see:
9154 java CALL
mmap
; I didn't think 2) changed? I.e. both the old and new code do this,
> so only 1)
> is changing?
you're right sorry about that mistake. so the only aspect of mmap() the patch
changes is:
if MAP_ANON is defined and offset !=0 > return EINVAL
cheers.
alex
___
On Saturday 07 November 2009 9:19:05 pm Alexander Best wrote:
> no problem. i've sent the final patch as followup to kern/71258 and also
> attached it to this message. to make it short. what's being changed by the
> patch:
>
> 1) if MAP_ANON is defined and offset !=0 > return EINVAL
> 2) if
no problem. i've sent the final patch as followup to kern/71258 and also
attached it to this message. to make it short. what's being changed by the
patch:
1) if MAP_ANON is defined and offset !=0 > return EINVAL
2) if MAP_STACK is defined and offset !=0 > offset = 0
would be great if
just had a look at the linux mmap(2) manual and noticed a very neat thing they
seem to have in most manuals:
in the ERRORS section they also document which signals one has to expect. for
mmap they are SIGSEGV and SIGBUS.
thanks very useful imo.
alex
Yes. If no one objects in the next day or so, then please commit
> this change.
> Alan
should this compatibility addition be documented in the mmap(2) manual?
any thoughts on the previous change request so mmap fails with MAP_ANON and
pos=0?
alex
_
Ed Schouten wrote:
* Alan Cox wrote:
For what it's worth, I believe that Solaris does the exact opposite.
They provide MAP_ANONYMOUS for compatibility. It seems like a good
idea for us to do the same.
Something like this?
Index: mman.h
===
* Alan Cox wrote:
> For what it's worth, I believe that Solaris does the exact opposite.
> They provide MAP_ANONYMOUS for compatibility. It seems like a good
> idea for us to do the same.
Something like this?
Index: mman.h
===
---
Ed Schouten wrote:
* John Baldwin wrote:
Note that the spec doesn't cover MAP_ANON at all FWIW.
Yes. I've noticed Linux also uses MAP_ANONYMOUS instead of MAP_ANON.
They do provide MAP_ANON for compatibility, if I remember correctly.
For what it's worth, I believe that Solaris d
* John Baldwin wrote:
> Note that the spec doesn't cover MAP_ANON at all FWIW.
Yes. I've noticed Linux also uses MAP_ANONYMOUS instead of MAP_ANON.
They do provide MAP_ANON for compatibility, if I remember correctly.
--
Ed Schouten
WWW: http://80386.nl/
pgpxciIJov3Hf.pgp
Description: PGP s
On Tuesday 03 November 2009 12:24:52 pm Ed Schouten wrote:
> Hi Alan,
>
> * Alan Cox wrote:
> > The standards for mmap(2) actually disallow values of "off" that are not a
> > multiple of the page size.
> >
> > See http://www.opengroup.org/onlinepub
; John Baldwin schrieb am 2009-10-21:
> > > > > > > > > On Wednesday 21 October 2009 11:51:04 am Alexander
> > > > > > > > > Best
> > > > > > > > > wrote:
> > > > > > > > > > although the
Hi Alan,
* Alan Cox wrote:
> The standards for mmap(2) actually disallow values of "off" that are not a
> multiple of the page size.
>
> See http://www.opengroup.org/onlinepubs/95399/functions/mmap.html for
> the following:
>
Just by accident I saw they chang
> > John Baldwin schrieb am 2009-11-02:
> > > > > > On Friday 30 October 2009 10:38:24 pm Alexander Best wrote:
> > > > > > > John Baldwin schrieb am 2009-10-21:
> > > > > > > > On Wednesday 21 October 2009 11:51
t; > On Friday 30 October 2009 10:38:24 pm Alexander Best wrote:
> > > > > > John Baldwin schrieb am 2009-10-21:
> > > > > > > On Wednesday 21 October 2009 11:51:04 am Alexander Best
> > > > > > > wrote:
> > >
wrote:
> > > > > John Baldwin schrieb am 2009-10-21:
> > > > > > On Wednesday 21 October 2009 11:51:04 am Alexander Best
> > > > > > wrote:
> > > > > > > although the mmap(2) manual states in section MAP_ANON:
>
> On Wednesday 21 October 2009 11:51:04 am Alexander Best
> > > > > wrote:
> > > > > > although the mmap(2) manual states in section MAP_ANON:
> > > > > > "The offset argument is ignored."
> > > > > > t
wrote:
> > > > > although the mmap(2) manual states in section MAP_ANON:
>
> > > > > "The offset argument is ignored."
>
> > > > > this doesn't seem to be true. running
>
> > > > > printf("%p\n", mmap(
John Baldwin schrieb am 2009-11-02:
> On Friday 30 October 2009 10:38:24 pm Alexander Best wrote:
> > John Baldwin schrieb am 2009-10-21:
> > > On Wednesday 21 October 2009 11:51:04 am Alexander Best wrote:
> > > > although the mmap(2) manual states in section
On Friday 30 October 2009 10:38:24 pm Alexander Best wrote:
> John Baldwin schrieb am 2009-10-21:
> > On Wednesday 21 October 2009 11:51:04 am Alexander Best wrote:
> > > although the mmap(2) manual states in section MAP_ANON:
>
> > > "The offset argument is i
John Baldwin schrieb am 2009-10-21:
> On Wednesday 21 October 2009 11:51:04 am Alexander Best wrote:
> > although the mmap(2) manual states in section MAP_ANON:
> > "The offset argument is ignored."
> > this doesn't seem to be true. running
> >
gt; > >don't
> > > >use the code for any other purpose. i was under the impression
> > > >that
> > > >mmap() should either succeed or fail (tertium non datur). mmap's
> > > >manual doesn't say anything about mmap() causing segfau
Alan Cox wrote:
On Wed, Oct 21, 2009 at 10:51 AM, Alexander Best <
alexbes...@math.uni-muenster.de> wrote:
although the mmap(2) manual states in section MAP_ANON:
"The offset argument is ignored."
this doesn't seem to be true. running
printf("%p\n", mmap((
On Wednesday 21 October 2009 11:51:04 am Alexander Best wrote:
> although the mmap(2) manual states in section MAP_ANON:
>
> "The offset argument is ignored."
>
> this doesn't seem to be true. running
>
> printf("%p\n", mmap((void*)0x1000,
rpose. i was under the impression that
> > >mmap() should either succeed or fail (tertium non datur). mmap's
> > >manual doesn't say anything about mmap() causing segfaults.
>
> > Have you tried ktracing the application? I think you'll find that
> >
1 - 100 of 457 matches
Mail list logo
