Messages in this thread | | | Date | Tue, 22 Mar 2005 06:08:38 +0000 (GMT) | From | Hugh Dickins <> | Subject | Re: [PATCH 1/5] freepgt: free_pgtables use vma list |
| |
On Mon, 21 Mar 2005, David S. Miller wrote: > On Tue, 22 Mar 2005 15:14:54 +1100 > Nick Piggin <nickpiggin@yahoo.com.au> wrote: > > > Question, Dave: flush_tlb_pgtables after Hugh's patch is also > > possibly not being called with enough range to cover all page > > tables that have been freed.
Good question from Nick.
> > For example, you may have a single page (start,end) address range > > to free, but if this is enclosed by a large enough (floor,ceiling) > > then it may free an entire pgd entry. > > > > I assume the intention of the API would be to provide the full > > pgd width in that case? > > It just wants the range of page tables liberated. I guess > essentially PMD_SIZE is the granularity.
I _think_ that answer means that my current code is fine in this respect. But I'm not entirely convinced. Since sparc64 is the only architecture which implements a flush_tlb_pgtables which actually uses start,end, we do need to suit your needs there - informed reassurance welcome!
> Anyways, for the record I made it only call flush_tlb_pgtables() > when end > start,
Fine. The patch I just sent, moving the tests, is how I'd like it to be fixed finally, but what you've done in the interim should do fine.
> but instead of that BUG() I now get the BUG() > on mm->nr_ptes being non-zero at the end of exit_mmap().
And no way would your change be causing this. Oh dear.
> Something is up with the floor/ceiling stuff methinks.
Seems so. I did have an off-by-one originally, but that version never leaked out.
> It's funny since this code aparently works fine on ia64 which > is fully 3-level too. Hmm...
Yes, odd. I'll have to have another think later on.
Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |