changing physical page

changing physical page

[yipee]

Hi,

On a system running without swap, can there be a case in which the
kernel decides to move (from one physical page to another)
a dynamically-allocated page owned by a user program?

Thanks,
y

Re: changing physical page

[linux-os (Dick Johnson)]

On Thu, 2 Feb 2006, yipee wrote:

> Hi,
>
> On a system running without swap, can there be a case in which the
> kernel decides to move (from one physical page to another)
> a dynamically-allocated page owned by a user program?
>
> Thanks,
> y

<yipeeyipeeyipeeyipee@yahoo.com>

I'll bet this is a one-shot-deal so you can tell somebody you
posted to the linux-kernel list!

The answer is absolutely, positively, maybe, especially on
Tuesdays.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.66 BogoMips).
Warning : 98.36% of all statistics are fiction.
_
To unsubscribe


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: changing physical page

[yipee]

linux-os (Dick Johnson <linux-os <at> analogic.com> writes:

[snip]

> I'll bet this is a one-shot-deal so you can tell somebody you
> posted to the linux-kernel list!

nope

> The answer is absolutely, positively, maybe, especially on
> Tuesdays.

why would the kernel memcpy an allocated page to a different physical location?

> 
> Cheers,
> Dick Johnson

y'r name fits

Re: changing physical page

[linux-os (Dick Johnson)]

On Thu, 2 Feb 2006, Richard B. Johnson wrote:

> On Thu, 2 Feb 2006, yipee wrote:
>
>> Hi,
>>
>> On a system running without swap, can there be a case in which the
>> kernel decides to move (from one physical page to another)
>> a dynamically-allocated page owned by a user program?
>>
>> Thanks,
>> y
>
> <yipeeyipeeyipeeyipee@yahoo.com>
>
> I'll bet this is a one-shot-deal so you can tell somebody you
> posted to the linux-kernel list!
>
> The answer is absolutely, positively, maybe, especially on
> Tuesdays.

I got the previous reply but accidentially deleted it. The
kernel may try to create some contiguous pages for DMA or
other usage. If some page in your task can be switched to
make that continuous allocation, it might be.

If your program(s) rely upon being in some physical location,
they are broken. Even with mlockall(), you just keep them
where they are, not where you'd like them to be. If you
are trying to DMA into/out-of user-space, there is only
ONE way to do it. Your driver allocates DMA-able pages and
your code mmaps() it into user-space. That way, the page(s)
are always present and have the right attributes. If you
malloc() something, then try to "convert" in the kernel
through your driver, the code's broken.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.66 BogoMips).
Warning : 98.36% of all statistics are fiction.
_
To unsubscribe


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: changing physical page

[yipee]

linux-os (Dick Johnson <linux-os <at> analogic.com> writes:

[snip]
 
> If your program(s) rely upon being in some physical location,
> they are broken. Even with mlockall(), you just keep them
> where they are, not where you'd like them to be. If you
> are trying to DMA into/out-of user-space, there is only
> ONE way to do it. Your driver allocates DMA-able pages and
> your code mmaps() it into user-space. That way, the page(s)
> are always present and have the right attributes. If you
> malloc() something, then try to "convert" in the kernel
> through your driver, the code's broken.

And all this page-moving for getting contiguous DMA memory, happens today on
x86_64 kernels?
Can you please give me a pointer to the source code?


Thanks

Re: changing physical page

[Hugh Dickins]

On Thu, 2 Feb 2006, yipee wrote:
> 
> On a system running without swap, can there be a case in which the
> kernel decides to move (from one physical page to another)
> a dynamically-allocated page owned by a user program?

I'll assume that when you say "page owned by a user program", you're
meaning a private page, not a shared file page mapped into the program.

If you're asking about what currently happens, the answer is "No".

If you're asking about what you can assume, the answer is "Yes".

The kernel is entitled to move them if it wishes, various people
are interested in page migration, and one application would be if
the system is short of free memory of a particular kind, and your
page is on such memory, and it would help to move it elsewhere.

Hugh

Re: changing physical page

[yipee]

Hugh Dickins <hugh <at> veritas.com> writes:

[snip]

> I'll assume that when you say "page owned by a user program", you're
> meaning a private page, not a shared file page mapped into the program.
> 
> If you're asking about what currently happens, the answer is "No".
> 
> If you're asking about what you can assume, the answer is "Yes".

So you are saying that the current kernel doesn't move these kind of pages? but
it may in future versions?


thanks,
y

Re: changing physical page

[Hugh Dickins]

On Sat, 4 Feb 2006, yipee wrote:
> Hugh Dickins <hugh <at> veritas.com> writes:
> > I'll assume that when you say "page owned by a user program", you're
> > meaning a private page, not a shared file page mapped into the program.
> > 
> > If you're asking about what currently happens, the answer is "No".
> > 
> > If you're asking about what you can assume, the answer is "Yes".
> 
> So you are saying that the current kernel doesn't move these kind of pages?

If you don't have swap (one of the conditions you gave), yes.

> but it may in future versions?

Yes.

Re: changing physical page

[Gleb Natapov]

On Sat, Feb 04, 2006 at 03:20:00PM +0000, Hugh Dickins wrote:
> On Sat, 4 Feb 2006, yipee wrote:
> > Hugh Dickins <hugh <at> veritas.com> writes:
> > > I'll assume that when you say "page owned by a user program", you're
> > > meaning a private page, not a shared file page mapped into the program.
> > > 
> > > If you're asking about what currently happens, the answer is "No".
> > > 
> > > If you're asking about what you can assume, the answer is "Yes".
> > 
> > So you are saying that the current kernel doesn't move these kind of pages?
> 
> If you don't have swap (one of the conditions you gave), yes.
> 
And what if application forks and writes to the private page? Kernel
actually memcpy the page to another location.

--
			Gleb.

Re: changing physical page

[Hugh Dickins]

On Sun, 5 Feb 2006, Gleb Natapov wrote:
> On Sat, Feb 04, 2006 at 03:20:00PM +0000, Hugh Dickins wrote:
> > On Sat, 4 Feb 2006, yipee wrote:
> > > Hugh Dickins <hugh <at> veritas.com> writes:
> > > > I'll assume that when you say "page owned by a user program", you're
> > > > meaning a private page, not a shared file page mapped into the program.
> > > > 
> > > > If you're asking about what currently happens, the answer is "No".
> > > > 
> > > > If you're asking about what you can assume, the answer is "Yes".
> > > 
> > > So you are saying that the current kernel doesn't move these kind of pages?
> > 
> > If you don't have swap (one of the conditions you gave), yes.
> > 
> And what if application forks and writes to the private page? Kernel
> actually memcpy the page to another location.

Good point.
Hugh