> The below patchlet changes the kmap_atomic interface to a stack based> one that doesn't require the KM_types anymore.> > This significantly simplifies some code (more still than are present in> this patch -- ie. pte_map_nested can go now)> ...> What do people think?

Brrr.

This makes FRV much worse. kmap_atomic() used to take a compile-time constantvalue - which meant that the switch-statement inside it was mostly optimisedaway. kmap_atomic() would be rendered down to very few instructions. Nowit'll be a huge jump table plus all those few instructions repeated becausethe selector is now dynamic.

What I would prefer to see is something along the lines of local_irq_save()and local_irq_restore(), where the displaced value gets stored on the machinestack. In FRV, I could then represent kmap_atomic() as:

And I would avoid the need to lock fake TLB entries in the shallow TLB.

If it's too much trouble for an arch to extract the current kmap setting fromthe MMU or the page tables, *those* could be mirrored in per-CPU data.

Do we have any code that uses two slots and then calls more code thatultimately requires further slots? In other words, do we need more than twoslots?

> David, frv has a 'funny' issue in that it treats __KM_CACHE special from> the other ones, something which isn't possibly anymore. Do you see> another option than to add kmap_atomic_push_cache() for frv?

The four __KM_xxx slots are special and must not be committed to this stack.They're used by assembly code directly for certain tasks, such as maintainingthe TLB-lookup state. Your changes are guaranteed to break MMU-mode FRV.

That said, there's no reason these four slots *have* to be administeredthrough kmap_atomic(). A kmap_frv() could be made instead for them.