Messages in this thread | | | Date | Fri, 25 Feb 2005 08:59:03 +1100 | From | Nick Piggin <> | Subject | Re: [PATCH 2/2] page table iterators |
| |
Hugh Dickins wrote: > On Thu, 24 Feb 2005, Nick Piggin wrote: > >>pud_addr_end? > > > next = pud_addr_end(addr, end); > > Hmm, yes, I'll go with that, thanks (unless a better idea follows). > > Something I do intend on top of what I sent before, is another set > of three macros, like > > if (pud_none_or_clear_bad(pud)) > continue; > > to replace all the p??_none, p??_bad clauses: not to save space, > but just for clarity, those loops now seeming dominated by the > unlikeliest of cases. > > Has anyone _ever_ seen a p??_ERROR message? I'm inclined to just > put three functions into mm/memory.c to do the p??_ERROR and p??_clear, > but that way the __FILE__ and __LINE__ will always come out the same. > I think if it ever proves a problem, we'd just add in a dump_stack. >
I think a function is the most sensible. And a good idea, it should reduce the icache pressure in the loops (although gcc does seem to do a pretty good job of moving unlikely()s away from the fastpath).
I think at the point these things get detected, there is little use for having a dump_stack. But we may as well add one anyway if it is an out of line function?
Nick
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |