Re: page->offset

Re: page->offset

[pnilesh]

To have your views,

If a file is opened and from an offset which is not page aligned say from
offset 10.
When we read this file into the memory page ,where the first byte will be
loaded into the memory ?
In 2.2 the first byte of the page will be the 10th byte of the file.
In 2.3 the first byte will be first byte in the file and 10th byte is the
10th in the file.

This is what I feel.

Nilesh

Correct.  There are some very old binary formats in which the pages
of the executable are not page-aligned.  2.2 still supports them
and allows such binaries to be non-aligned in cache, but there is
no guarantee of cache coherency on such mappings and they are no
longer supported in 2.3.

--Stephen



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: page->offset

[Stephen C. Tweedie]

Hi,

On Wed, Apr 12, 2000 at 06:34:21PM +0530, pnilesh@in.ibm.com wrote:
> 
> If a file is opened and from an offset which is not page aligned say from
> offset 10.
> When we read this file into the memory page ,where the first byte will be
> loaded into the memory ?
> In 2.2 the first byte of the page will be the 10th byte of the file.
> In 2.3 the first byte will be first byte in the file and 10th byte is the
> 10th in the file.

No.  The cache will always be page aligned in both 2.2 and 2.3 for
all user IO and for all mmap()ed files.  The _only_ case where we
allow non-aligned mappings is when the execve() syscall is executed
on a QMAGIC binary, in which case 2.2 will allow the mapping and
will page the binary in at unaligned offsets when page faults occur.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: page->offset

[Eric W. Biederman]

pnilesh@in.ibm.com writes:

> To have your views,
> 
> If a file is opened and from an offset which is not page aligned say from
> offset 10.
Umm.  Files aren't opend with offsets.
The are however mapped at offsets.

> When we read this file into the memory page ,where the first byte will be
> loaded into the memory ?
When you mmap the file?  A read syscall isn't affected?

> In 2.2 the first byte of the page will be the 10th byte of the file.
Nope.  Can't do alignments less the fs blocksize which at least 512 bytes
even in 2.2.  But for the mmap case you are substantailly correct.

> In 2.3 the first byte will be first byte in the file and 10th byte is the
> 10th in the file.
That is what will be in the cache.   The mmap  request will simply be refused.

> This is what I feel.

How does feelings have anything to do with it?

Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: page->offset

[pnilesh]

Odd, it should't.  Which kernel is this?
cat /proc/version shows  2.2.5-15

>         char *p = mmap (NULL,10,PROT_READ,MAP_SHARED,fd,1024);
>         char *s = mmap (NULL,10,PROT_READ,MAP_SHARED,fd,1024);

strace shows:

  old_mmap(NULL, 10, PROT_READ, MAP_SHARED, 3, 0x400) = -1 EINVAL (Invalid
argument)
  old_mmap(NULL, 10, PROT_READ, MAP_SHARED, 3, 0x400) = -1 EINVAL (Invalid
argument)

on a 1k blocksize filesystem.

> Does these virtual addresses point to only one physical page ?
> This page is in the page cache if I am not wrong with page->count = 3 ?
> (2.2.x)

Correct.

> If I do read () from 1024 offset the data I will get will be from the
above
> phyiscal page or from .... ?

read() _always_ invokes the page cache with pagesize-aligned
page offsets.  If a correctly aligned page is not present, a new one
will be created.


Nilesh


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: page->offset

[pnilesh]

I think I had put up the question in a wrong way.

If I mmap a file from/at a particular offset.
char *p;
fd = open("anyfile");
p = mmap (NULL,100,PROT_READ|PROT_WRITE, MAP_SHARED,fd,10);

Here the call fails .
I tried to map at / from offset 512 that also failed.
however with the offset of 1024 it succeded.

So I can not mmap anything which is not fs block size aligned .

#include <unistd.h>
#include <sys/mman.h>
#include <fcntl.h>
main (int argc, char **argv)
{
        int i = 0;
        int fd = open("./anyfile",O_RDWR);
        char *p = mmap (NULL,10,PROT_READ,MAP_SHARED,fd,1024);
        char *s = mmap (NULL,10,PROT_READ,MAP_SHARED,fd,1024);
        char *q = 0;

        q = (char*)((int)p & 0xfffff000);
        printf ("p %x masked p %x\n",p,q);
        q = (char*)((int)s & 0xfffff000);
        printf ("s %x masked s %x\n",s,q);
}
The output of this was
p 40014000 masked p 40014000
s 40015000 masked s 40015000

Does these virtual addresses point to only one physical page ?
This page is in the page cache if I am not wrong with page->count = 3 ?
(2.2.x)


If I do read () from 1024 offset the data I will get will be from the above

phyiscal page or from .... ?

Nilesh




--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: page->offset

[Matti Aarnio]

On Thu, Apr 13, 2000 at 10:23:03AM +0530, pnilesh@in.ibm.com wrote:
> I think I had put up the question in a wrong way.
> 
> If I mmap a file from/at a particular offset.
>   char *p;
>   fd = open("anyfile");
>   p = mmap (NULL,100,PROT_READ|PROT_WRITE, MAP_SHARED,fd,10);
> 
> Here the call fails .
> I tried to map at / from offset 512 that also failed.
> however with the offset of 1024 it succeded.
>
> So I can not mmap anything which is not fs block size aligned .

	Actually you should not be able to map anything which is
	not MACHINE PAGE SIZE aligned -- not map shared, that is.
	It is somewhat accidental that 2.2 allows FS block size
	alignment.   A  MAP_PRIVATE  may allow other offsets.

	In 2.4 the 'page->offset' field is gone, and it is known
	as 'page->index', which is scaled version of offset value.
	Scaled with PAGE SIZE.

	Reason for going to this has been (among others) to get
	coherency into the page cache so that there won't be
	differently aligned copies of same byte range in the memory.

> Nilesh

/Matti Aarnio
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: page->offset

[Andrea Arcangeli]

On Thu, 13 Apr 2000, Matti Aarnio wrote:

>	Scaled with PAGE SIZE.

PAGE_CACHE_SIZE

>	Reason for going to this has been (among others) to get
>	coherency into the page cache so that there won't be
>	differently aligned copies of same byte range in the memory.

Very right. Other strong reason was to avoid long long with LFS.

Andrea

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: page->offset

[Stephen C. Tweedie]

Hi,

On Thu, Apr 13, 2000 at 10:23:03AM +0530, pnilesh@in.ibm.com wrote:
> 
> Here the call fails .
> I tried to map at / from offset 512 that also failed.
> however with the offset of 1024 it succeded.

Odd, it shouldn't.  Which kernel is this?

>         char *p = mmap (NULL,10,PROT_READ,MAP_SHARED,fd,1024);
>         char *s = mmap (NULL,10,PROT_READ,MAP_SHARED,fd,1024);

strace shows:

  old_mmap(NULL, 10, PROT_READ, MAP_SHARED, 3, 0x400) = -1 EINVAL (Invalid argument)
  old_mmap(NULL, 10, PROT_READ, MAP_SHARED, 3, 0x400) = -1 EINVAL (Invalid argument)

on a 1k blocksize filesystem.

> Does these virtual addresses point to only one physical page ?
> This page is in the page cache if I am not wrong with page->count = 3 ?
> (2.2.x)

Correct.

> If I do read () from 1024 offset the data I will get will be from the above
> phyiscal page or from .... ?

read() _always_ invokes the page cache with pagesize-aligned
page offsets.  If a correctly aligned page is not present, a new one
will be created.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

page->offset

[pnilesh]

This is related to 2.2.x


One of the comment in mm.h says that we can have more than one copy of some
page of an executable or shared lib (not normally).

Does it have to do something with offet field in page structure ?
Does it mean that it may happen becoz offset field is not guarenteed to be
PAGE_SIZE aligned  ?

Nilesh Patel


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: page->offset

[Stephen C. Tweedie]

Hi,

On Wed, Apr 12, 2000 at 03:37:37PM +0530, pnilesh@in.ibm.com wrote:
> 
> One of the comment in mm.h says that we can have more than one copy of some
> page of an executable or shared lib (not normally).
> 
> Does it have to do something with offet field in page structure ?
> Does it mean that it may happen becoz offset field is not guarenteed to be
> PAGE_SIZE aligned  ?

Correct.  There are some very old binary formats in which the pages
of the executable are not page-aligned.  2.2 still supports them
and allows such binaries to be non-aligned in cache, but there is
no guarantee of cache coherency on such mappings and they are no
longer supported in 2.3.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/