On Wed, 2009-06-17 at 17:43 +0900, Tejun Heo wrote: > Hello, > > Peter Zijlstra wrote: > > On Tue, 2009-06-16 at 13:38 +0100, Hugh Dickins wrote: > >> Something else to throw in: what if they were not just atomic, > >> but also replaced the current sleeping kmaps? i.e. a task context > >> carries around its own stack of these. > > > > I actually did that once, but it means the task needs to be cpu-affine, > > because fixmaps have different addresses between cpus. And disabling > > migration for tasks has subtle side-effects so I dropped that again. > > > > However, I recently considered the possiblity of putting the fixmaps in > > the new per-cpu address space so that we might use the %gs segment to > > normalize the fixmap addresses between the cpus. > > > > This would allow full preemptible kmaps (yay for -rt). > > > > However I suspect it might greatly complicate kmaps for the !i386 world. > > Other archs are in the process of conversion so once that is complete, > there's no reason this should be more difficult but it means that > kmapped addresses should be accessed differently from regular ones > which we can't do. :-( Right, we'd need percpu_memset, percpu_copy_from, percpu_copy_to, etc. that all operate on %gs like addrs. might be a tad invasive. -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|