On Sun, 2011-07-17 at 09:49 +1000, Benjamin Herrenschmidt wrote: > In the meantime, other than rewriting the futex code to not require > those in-atomic accesses (can't it just access the pages via the linear > mapping and/or kmap after the gup ?),
That'll wreck performance on things like ARM and SPARC that have to deal with cache aliasing. > all I see would be a way to force > dirty and young after gup, with appropriate locks, or a variant of gup > (via a flag ?) to require it to do so. Again, _WHY_ isn't gup(.write=1) a complete write fault? Its supposed to be, it needs to break COW, do dirty page tracking and call page_mkwrite. I'm still thinking this e500 stuff is smoking crack. ARM has no hardware dirty bit either, and yet it works for them. I can't exactly tell how because I got lost in there, but it does, again, suggest e500 is on crack. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
