On Thu, May 07, 2015 at 02:14:39PM +0200, David Hildenbrand wrote: > Thanks :), well just to make sure I got your opinion on this correctly: > > 1. You think that 2 counters is the way to go for now ack > 2. You agree that we can't replace preempt_disable()+pagefault_disable() with > preempt_disable() (CONFIG_PREEMPT stuff), so we need to have them separately ack > 3. We need in_atomic() (in the fault handlers only!) in addition to make sure we > don't mess with irq contexts (In that case I would add a good comment to that > place, describing why preempt_disable() won't help) ack > I think this is the right way to go because: > > a) This way we don't have to modify preempt_disable() logic (including > PREEMPT_COUNT). > > b) There are not that many users relying on > preempt_disable()+pagefault_disable() (compared to pure preempt_disable() or > pagefault_disable() users), so the performance overhead of two cache lines > should be small. Users only making use of one of them should see no difference > in performance. indeed. > c) We correctly decouple preemption and pagefault logic. Therefore we can now > preempt when pagefaults are disabled, which feels right. Right, that's always been the intent of introducing pagefault_disable(). -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
