kmap_atomic

Posted Aug 5, 2009 14:48 UTC (Wed) by arjan (subscriber, #36785)
Parent article: The realtime preemption endgame

turning kmap_atomic into a full kmap sounds a bit overkill, one could do a per cpu kmap like pool, and then pin the task to the cpu for the duration of the kmap... saves the cross-cpu IPIs that kmap_atomic tries to eliminate from kmap...

kmap_atomic

Posted Aug 5, 2009 14:56 UTC (Wed) by corbet (editor, #1) [Link] (2 responses)

That wouldn't quite do it - you still have to avoid contention for the atomic kmap slots or chaos will result. That generally implies disabling preemption, which is what they're trying to avoid. I suppose one could implement some sort of slot-management layer so that one task's KM_USER0 is different from another's, but that sounds messy...

kmap_atomic

Posted Aug 5, 2009 17:28 UTC (Wed) by iq-0 (subscriber, #36655) [Link] (1 responses)

So if it were performance-wise feasible to make kmaps local per thread (part
of a thread switch) the whole kmap_atomic and kmap could be folded back
into one implementation?

kmap_atomic

Posted Aug 6, 2009 16:06 UTC (Thu) by ebiederm (subscriber, #35028) [Link]

Just don't allow highmem and RT.