| |||||||||||||
kmap_atomickmap_atomicPosted 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...
(Log in to post comments)
kmap_atomic Posted Aug 5, 2009 14:56 UTC (Wed) by corbet (editor, #1) [Link] 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]
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.
|
|||||||||||||