Re: question on symbol exports

I've added the ppc64 list to the addressees, in case they are interested.


Marcelo Tosatti wrote:

On Tue, Feb 01, 2005 at 04:50:16PM +0100, Arjan van de Ven wrote:

quoted

afaik one doesn't need to do a tlb flush in code that clears the dirty
bit, as long as you use the proper vm functions to do so. 
(if those need a tlb flush, those are supposed to do that for you
afaik).

Yep, and "proper VM function" is include/asm-generic/pgtable.h::ptep_clear_flush_dirty(),
which on PPC flushes the TLB.

It turns out that to call ptep_clear_flush_dirty() on ppc64 from a 
module I needed to export the following symbols:

__flush_tlb_pending
ppc64_tlb_batch
hpte_update

quoted

Also note that your code isn't dealing with 4 level pagetables.... And
pagetable walking in drivers is basically almost always a mistake and a
sign that something is wrong.

Or a sign that the core kernel lacks helper functions :) 

Absolutely.  It'd be so nice if there was a simple va_to_ptep() helper 
function available.

Chris

It turns out that to call ptep_clear_flush_dirty() on ppc64 from a 
module I needed to export the following symbols:

__flush_tlb_pending
ppc64_tlb_batch
hpte_update

Any reason why you need to call that from a module ? Is the module
GPL'd ?

Ben.

Benjamin Herrenschmidt wrote:

quoted

It turns out that to call ptep_clear_flush_dirty() on ppc64 from a 
module I needed to export the following symbols:

__flush_tlb_pending
ppc64_tlb_batch
hpte_update

Any reason why you need to call that from a module ? Is the module
GPL'd ?

I explained this at the beginning of the thread, but I'll do so again. 
The module will be released under the GPL.

The basic idea is that we want to be able to track pages dirtied by a 
userspace process.  The system has no swap, so we use the dirty bit for 
this.  On demand we look up the page tables for an address range 
specified by the caller, store the addresses of any dirty pages, then 
mark them clean so that the next write causes them to get marked dirty 
again.  It is this act of marking them clean that requires the 
additional exports.

I've included the current code below.  If there is any way to accomplish 
this without the additional exports, I'd love to hear about it.

Chris








Note: this code is run while holding &mm->mmap_sem and &mm->page_table_lock.


for(addr=start&PAGE_MASK; addr<=end; addr+=PAGE_SIZE) {
	pte_t *ptep=0;

	ptep = va_to_ptep_map(mm, addr);
	if (!ptep)
		goto unmap_continue;

	if (!pte_dirty(*ptep))
		goto unmap_continue;

	/* We have a user readable dirty page.  Count it.*/
	dirty_count++;

	if (dirty_count <= entries) {
		__put_user(addr, buf);
		buf++;
		ptep_clear_flush_dirty(find_vma(mm, addr), addr, ptep);

		/* Handle option to stop early. */
		if ((dirty_count == entries) &&
			(options & STOP_WHEN_BUF_FULL))
			addr=end+1;
	}

unmap_continue:
	if (ptep)
		pte_unmap(ptep);		
}

On Mon, 2005-02-07 at 08:44 -0600, Chris Friesen wrote:

Benjamin Herrenschmidt wrote:

quoted

quoted

It turns out that to call ptep_clear_flush_dirty() on ppc64 from a 
module I needed to export the following symbols:

__flush_tlb_pending
ppc64_tlb_batch
hpte_update

Any reason why you need to call that from a module ? Is the module
GPL'd ?

I explained this at the beginning of the thread, but I'll do so again. 
The module will be released under the GPL.

The basic idea is that we want to be able to track pages dirtied by a 
userspace process.  The system has no swap, so we use the dirty bit for 
this.  On demand we look up the page tables for an address range 
specified by the caller, store the addresses of any dirty pages, then 
mark them clean so that the next write causes them to get marked dirty 
again.  It is this act of marking them clean that requires the 
additional exports.

I've included the current code below.  If there is any way to accomplish 
this without the additional exports, I'd love to hear about it.

Interesting... more than no swap, you must also make sure you have no
r/w mmap'ed file (which are technically equivalent to swap).

I'm not too fan about exporting those symbols, but I'll talk to paulus,
it should be possible at least to EXPORT_SYMBOL_GPL them...

Ben.

Benjamin Herrenschmidt wrote:

Interesting... more than no swap, you must also make sure you have no
r/w mmap'ed file (which are technically equivalent to swap).

Ah...thanks for the warning.

We want to eventually make it work with swap as well, but that's 
substantially more complicated.

I'm not too fan about exporting those symbols, but I'll talk to paulus,
it should be possible at least to EXPORT_SYMBOL_GPL them...

I understand the reluctance.  I'm perfectly willing to export it GPL in 
my private branch as long as you guys don't consider it evil--the module 
is going to be GPL anyways.

The alternative would be for me to build my code directly in to the 
kernel...just makes it harder for me to debug.

Chris

On Feb 7, 2005, at 4:35 PM, Benjamin Herrenschmidt wrote:

Interesting... more than no swap, you must also make sure you have no
r/w mmap'ed file (which are technically equivalent to swap).

Yeah, I kinda had a similar thought.  Just because you aren't
swapping doesn't mean the VM subsystem isn't looking at dirty bits,
too.  It could potentially steal a page that it thinks can be replaced
from either a zero-fill or reading again from persistent storage.


	-- Dan

Dan Malek wrote:

On Feb 7, 2005, at 4:35 PM, Benjamin Herrenschmidt wrote:

quoted

Interesting... more than no swap, you must also make sure you have no
r/w mmap'ed file (which are technically equivalent to swap).

Yeah, I kinda had a similar thought.  Just because you aren't
swapping doesn't mean the VM subsystem isn't looking at dirty bits,
too.  It could potentially steal a page that it thinks can be replaced
from either a zero-fill or reading again from persistent storage.

In our existing case, the app also mlock()s the pages in question.  This 
should get around these two possible sources of inaccuracy.

Chris