follow_page()

follow_page()

[Andrew Morton]

Can anyone think of a sane reason why this thing is marking the page dirty?

I mean, we're supposed to mark the page dirty _after_ modifying its
contents.
--
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-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: follow_page()

[Arjan van de Ven]

On Thu, 2004-11-11 at 02:40 -0800, Andrew Morton wrote:
> Can anyone think of a sane reason why this thing is marking the page dirty?
> 
> I mean, we're supposed to mark the page dirty _after_ modifying its
> contents.

most likely it's because the intent to write to it is given.
It's cheaper for the OS to mark a pagetable dirty than it's for the CPU
to do so (example, on a Pentium 4 it can easily take the cpu 2000 to
4000 cycles to flip the dirty bit on the PTE). So if you KNOW you're
going to write to it (and thus the intent parameter) you can save a big
chunk of those cycles.
-- 

--
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-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: follow_page()

[Andrew Morton]

Arjan van de Ven <arjan@infradead.org> wrote:
>
> On Thu, 2004-11-11 at 02:40 -0800, Andrew Morton wrote:
> > Can anyone think of a sane reason why this thing is marking the page dirty?
> > 
> > I mean, we're supposed to mark the page dirty _after_ modifying its
> > contents.
> 
> most likely it's because the intent to write to it is given.
> It's cheaper for the OS to mark a pagetable dirty than it's for the CPU
> to do so (example, on a Pentium 4 it can easily take the cpu 2000 to
> 4000 cycles to flip the dirty bit on the PTE). So if you KNOW you're
> going to write to it (and thus the intent parameter) you can save a big
> chunk of those cycles.

But it's racy.  writeback can write-and-clean the page before we've
modified its contents.  Whether the page contents are altered via disk DMA
or a memset or whatever, we can lose the data.  Except callers are
correctly dirtying the page after modifying it anyway.

--
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-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: follow_page()

[Arjan van de Ven]

> > most likely it's because the intent to write to it is given.
> > It's cheaper for the OS to mark a pagetable dirty than it's for the CPU
> > to do so (example, on a Pentium 4 it can easily take the cpu 2000 to
> > 4000 cycles to flip the dirty bit on the PTE). So if you KNOW you're
> > going to write to it (and thus the intent parameter) you can save a big
> > chunk of those cycles.
> 
> But it's racy.  writeback can write-and-clean the page before we've
> modified its contents.  Whether the page contents are altered via disk DMA
> or a memset or whatever, we can lose the data.  Except callers are
> correctly dirtying the page after modifying it anyway.

so in the race case you get the hit of those 4000 cycles... still optimizes the non-race case 
(so I'd agree that nothing should depend on this function dirtying it; it's a pre-dirty that's an
optimisation)

--
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-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: follow_page()

[Nick Piggin]

Arjan van de Ven wrote:
>>>most likely it's because the intent to write to it is given.
>>>It's cheaper for the OS to mark a pagetable dirty than it's for the CPU
>>>to do so (example, on a Pentium 4 it can easily take the cpu 2000 to
>>>4000 cycles to flip the dirty bit on the PTE). So if you KNOW you're
>>>going to write to it (and thus the intent parameter) you can save a big
>>>chunk of those cycles.
>>
>>But it's racy.  writeback can write-and-clean the page before we've
>>modified its contents.  Whether the page contents are altered via disk DMA
>>or a memset or whatever, we can lose the data.  Except callers are
>>correctly dirtying the page after modifying it anyway.
> 
> 
> so in the race case you get the hit of those 4000 cycles... still optimizes the non-race case 
> (so I'd agree that nothing should depend on this function dirtying it; it's a pre-dirty that's an
> optimisation)
> 

Only it doesn't mark the pte dirty, does it?

                 if (pfn_valid(pfn)) {
                         page = pfn_to_page(pfn);
                         if (write && !pte_dirty(pte) && !PageDirty(page))
                                 set_page_dirty(page);
                         mark_page_accessed(page);
                         return page;
                 }

So the CPU will still need to flip the dirty bit on the next write anyway.

It must be some leftover cruft to try to ensure the dirty bit doesn't get lost,
because it's going out of its way not to set the page dirty if the pte is dirty.

Kill it..?

--
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-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: follow_page()

[Andrew Morton]

Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
> Kill it..?

Think so.  We'd need to review all callers to make sure that they really
are marking pages dirty after modifying them.  Right now someone may just
be feeling lucky.

(looks at access_process_vm, wonders why it isn't doing flush_dcache_page).
--
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-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: follow_page()

[Nick Piggin]

Andrew Morton wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
>>Kill it..?
> 
> 
> Think so.  We'd need to review all callers to make sure that they really
> are marking pages dirty after modifying them.  Right now someone may just
> be feeling lucky.
> 
> (looks at access_process_vm, wonders why it isn't doing flush_dcache_page).
> 

Is it because copy_{to,from}_user_page already does flushing?
Looks like it... sorry, I'm not quite up to speed on this so
I'll stop talking crap for now :)

I think you're definitely right about your original concern
though, and the callers should be all checked.
--
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-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: follow_page()

[Arjan van de Ven]

> > so in the race case you get the hit of those 4000 cycles... still optimizes the non-race case 
> > (so I'd agree that nothing should depend on this function dirtying it; it's a pre-dirty that's an
> > optimisation)
> > 
> 
> Only it doesn't mark the pte dirty, does it?

sounds like someone subsequently "optimized" it...
predirtying the pte is still worth it imo....
but when we do that we better put a big fat comment there.


--
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-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: follow_page()

[Nick Piggin]

Arjan van de Ven wrote:
>>>so in the race case you get the hit of those 4000 cycles... still optimizes the non-race case 
>>>(so I'd agree that nothing should depend on this function dirtying it; it's a pre-dirty that's an
>>>optimisation)
>>>
>>
>>Only it doesn't mark the pte dirty, does it?
> 
> 
> sounds like someone subsequently "optimized" it...
> predirtying the pte is still worth it imo....
> but when we do that we better put a big fat comment there.
> 

Well, if you write into the page returned via follow_page, that
isn't going to dirty the pte by itself... so it is a bit of a
hit and miss regarding whether the page really will get dirtied
through that pte in the near future (I don't know, maybe that
is generally what happens with normal usage patterns?).
--
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-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: follow_page()

[Arjan van de Ven]

> Well, if you write into the page returned via follow_page, that
> isn't going to dirty the pte by itself... so it is a bit of a
> hit and miss regarding whether the page really will get dirtied
> through that pte in the near future (I don't know, maybe that
> is generally what happens with normal usage patterns?).

that's why the function has a parameter saying it is for writing too, I
think...

either way this deserves some comments in the code...
-- 

--
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-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>