flush_tlb_all in vmalloc_area_pages

flush_tlb_all in vmalloc_area_pages

[Andrea Arcangeli]

can somebody see a good reason for flushing the tlb in vmalloc? We must
do that in vfree but doing it in vmalloc is just a waste of time, we are
guaranteed that's an unmapped space before we start setting up the
pagetables so such address space cannot be cached in any tlb in first
place.

For the flush_cache_all for the virtually indexed caches should be the
same issue in theory (at least the kmap logic only needs to flush the
caches before the unmapping [not before the mapping] too)

Am I missing something, Dave?

--- 2.4.10pre4aa1/mm/vmalloc.c.~1~	Sat May 26 04:03:50 2001
+++ 2.4.10pre4aa1/mm/vmalloc.c	Fri Sep  7 16:53:41 2001
@@ -144,7 +144,6 @@
 	int ret;
 
 	dir = pgd_offset_k(address);
-	flush_cache_all();
 	spin_lock(&init_mm.page_table_lock);
 	do {
 		pmd_t *pmd;
@@ -164,7 +163,6 @@
 		ret = 0;
 	} while (address && (address < end));
 	spin_unlock(&init_mm.page_table_lock);
-	flush_tlb_all();
 	return ret;
 }
 
Andrea

Re: flush_tlb_all in vmalloc_area_pages

[David S. Miller]

   From: Andrea Arcangeli <andrea@suse.de>
   Date: Fri, 7 Sep 2001 16:56:12 +0200
   
   For the flush_cache_all for the virtually indexed caches should be the
   same issue in theory (at least the kmap logic only needs to flush the
   caches before the unmapping [not before the mapping] too)
   
   Am I missing something, Dave?

Anything that creates or takes away vmalloc() mappings needs to flush
the data cache if it is virtuall indexed.

I am always uncomfortable when I see people suggesting to remove
flushes from kernel virtual mapping setup/teardown.

Later,
David S. Miller
davem@redhat.com

Re: flush_tlb_all in vmalloc_area_pages

[Andrea Arcangeli]

On Thu, Sep 20, 2001 at 02:26:38PM -0700, David S. Miller wrote:
>    From: Andrea Arcangeli <andrea@suse.de>
>    Date: Fri, 7 Sep 2001 16:56:12 +0200
>    
>    For the flush_cache_all for the virtually indexed caches should be the
>    same issue in theory (at least the kmap logic only needs to flush the
>    caches before the unmapping [not before the mapping] too)
>    
>    Am I missing something, Dave?
> 
> Anything that creates or takes away vmalloc() mappings needs to flush
> the data cache if it is virtuall indexed.

The only question I'd like to get a answer is "what is actually the
data that can be virtually indexed) in the vmalloc range at the time we
run vmalloc?" Where does it cames from?

If there is no such data (as I think), we obviously don't need to flush
the virtually indexed caches at vmalloc time (but just at vfree).

Furthmore I recall on sparc you cannot flush the cache if you don't have
a mapping in place, and when you run vmalloc there should be no mapping
in place for the region of cache that you're trying to flush (or we
wouldn't trap the invalid faults there).

If anybody is using at boot time the vmalloc range for whatever purpuse
it should be its own business to flush the cache before dropping the
mappings from there.

Andrea

Re: flush_tlb_all in vmalloc_area_pages

[David S. Miller]

   From: Andrea Arcangeli <andrea@suse.de>
   Date: Fri, 21 Sep 2001 00:25:47 +0200

   The only question I'd like to get a answer is "what is actually the
   data that can be virtually indexed) in the vmalloc range at the time we
   run vmalloc?" Where does it cames from?
   
>From the the direct PAGE_OFFSET mappings.

   Furthmore I recall on sparc you cannot flush the cache if you don't have
   a mapping in place,

This is only true of Hypersparc sparc32 chips for page based flushes,
not whole flushes.

   If anybody is using at boot time the vmalloc range for whatever purpuse
   it should be its own business to flush the cache before dropping the
   mappings from there.
   
That isn't the problem, it's dirty cache lines left over from the
usual access addresses for physical memory (ie. via PAGE_OFFSET linear
mappings).

Please, I would heavily suggest leaving this area until 2.5.x there
are already a traumatic amount of changes going on in 2.4.x

Later,
David S. Miller
davem@redhat.com

   

Re: flush_tlb_all in vmalloc_area_pages

[Andrea Arcangeli]

On Thu, Sep 20, 2001 at 03:29:19PM -0700, David S. Miller wrote:
> Please, I would heavily suggest leaving this area until 2.5.x there

ok

Andrea

Re: flush_tlb_all in vmalloc_area_pages

[Andrea Arcangeli]

On Fri, Sep 21, 2001 at 12:38:45AM +0200, Andrea Arcangeli wrote:
> On Thu, Sep 20, 2001 at 03:29:19PM -0700, David S. Miller wrote:
> > Please, I would heavily suggest leaving this area until 2.5.x there
> 
> ok

Linus please apply to next pre patch, I understood from David that for
him the direct mapping can overlap the vmalloc virtual address space, it
really doesn't make much sense to me but since this is a noop for me and
I trust him, we can really delay this to 2.5:

--- 2.4.10pre12aa2/mm/vmalloc.c.~1~	Thu Sep 20 01:44:20 2001
+++ 2.4.10pre12aa2/mm/vmalloc.c	Fri Sep 21 00:40:48 2001
@@ -144,6 +144,7 @@
 	int ret;
 
 	dir = pgd_offset_k(address);
+	flush_cache_all();
 	spin_lock(&init_mm.page_table_lock);
 	do {
 		pmd_t *pmd;

And btw, now I suspect David can have also have an arguments for the
tlb_flush removal (infact the problem is the same, if the address space
is shared by direct mapping and vmalloc we'd also need to flush the
tlb), but such one isn't really a noop for the other archs so I will be
more concerned not to reintroduce it and to at least just put an #ifndef
__i386__ around it (safe for both parts).

Andrea