Re: [PATCH] Fix to make check_pgt_cache work on !i386 architectures

[Andreas Schwab]

Jakub Jelinek <[e-mail]> writes:

|> The solution you use might be applicable to sparc64 UP, but would give very
|> bad results for sparc32 SMP.

Ok, i understand now.  Since m68k is still completely UP i have never
thought too much about this.

|> If some page has a couple of chunks in one CPUs
|> quicklist, other chunks in other CPUs, some chunks allocated to different
|> CPUs and some out of any quicklists, it would create really horrible
|> fragmentation. There has to be some locking even in the check_pgt_cache
|> case (as currently implemented in srmmu_check_pgt_cache).

I'm wondering how the locking can be avoided at all on MP, since a page
table can be allocated by one CPU and freed by the next one.  Apparently
you avoided the problem in sparc64 SMP by wasting half of each page
allocated for pgds (which isn't that bad since there aren't too many of
them).  But for fractional pmd pages this would not be a solution.

|> What I don't like on your solution is that you basically maintain two lists
|> instead of one (one is the pmd_quicklist, the other is the internal
|> get_pointer_table list), have to go back and forth between those lists.

I didn't write {get,free}_pointer_table, they are basically unchanged from
day one.  I have just put the pgd/pmd cache on top of it.

|> And no matter which solution you use for m68k, I think it would be much
|> better to overload some unused struct page entries (like it is done on
|> sparc32/sparc64), instead of allocating the get_pointer_table internal
|> structures by kmalloc. And, you should not need any cli() there...

Thanks, i've now implemented your suggestions.  It's always worth looking
at some old code.

Andreas.

-- 
Andreas Schwab                                      "And now for something
[e-mail]              completely different"
[e-mail]