![]() | |||||||||||||
Messages in this thread |
Hugh Dickins wrote: > On Mon, 23 May 2005, William Lee Irwin III wrote: > >>On Mon, May 23, 2005 at 05:14:06PM -0700, Andrew Morton wrote: >> >>>I must say that I continue to find this approach a bit queazifying. >>>After some reading of the code I'd agree that yes, it's not possible for us >>>to get here with `pte' pointing at the first slot of the pte page, but it's >>>not 100% obvious and it's possible that someone will come along later and >>>will change things in try_to_unmap_cluster() which cause this unmap to >>>suddenly do the wrong thing in rare circumstances. >>>IOW: I'd sleep better at night if we took a temporary and actually unmapped >>>the thing which we we got back from pte_offset_map().. Am I being silly? > > > There's a similar argument for queasiness in all the other (8 or more) > instances of the idiom. I think we originally adopted (and I furthered) > this pte_unmap(pte - 1) idiom because in the majority of architecture's > configurations pte_unmap does nothing at all, so we resented assigning > a pointless variable in some critical loops. > Still, the compiler should be able to eliminate that extra register as well as it can eliminate the intermediate (pte - 1) result (that is to say, I hope perfectly in this day and age). It may be more of an issue with architectures that actually *do* do something in pte_unmap, in which case perhaps you increase the register pressure over the critical loop? I guess we can just laugh at them. > >>Not at all. I merely attempt to minimize diffsize by default. An >>alternative implementation follows (changelog etc. to be taken >>from the prior patch) in case it saves the time (however short) needed >>to write it yourself. > > > Either of wli's patches is fine with me. There are several levels on > which try_to_unmap_cluster is harder to understand than the others, > and no good reason to resist the variable assignment. > > We could rewrite pte_unmap to avoid the issue completely, since its > job is to unmap (or pretend to unmap) KM_PTE0's pte if the address > is in the fixmap area: but changing it to tolerate an off-by-one > address gives a queasy feeling too. > Looks like no architecture (other than maybe frv?) even uses the kvaddr argument to kunmap_atomic unless HIGHMEM_DEBUG/DEBUG_HIGHMEM is enabled. If you stored that info elsewhere, you wouldn't even need to pass the argument in. But hmm... I don't see anyone getting motivated enough to rewrite the debug code over this issue :) -- SUSE Labs, Novell Inc. - 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/ | ||||||||||||
| Last update: 2005-05-24 10:08 [from the cache] ©2003-2008 | |||||||||||||