On Tue, 15 Sep 2020 at 13:05, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Sep 15, 2020 at 01:02:10PM +0300, Ard Biesheuvel wrote: > > > > > I'd rather go for a preemptible/sleepable version of highmem mapping > > > which is in itself consistent for both highmen and not highmem. > > > > I don't think we need to obsess about highmem, although we should > > obviously take care not to regress its performance unnecessarily. What > > I want to avoid is to burden a brand new subsystem with legacy highmem > > baggage simply because we could not agree on how to avoid that. > > I think what Thomas is proposing should address your concerns Ard. > As long as nobody objects to the slight performance degradation on > legacy highmem platforms it should make kmap_atomic just go away on > modern platforms. > But making atomic kmap preemptible/sleepable creates the exact same problem, i.e., that we have no idea which existing callers are currently relying on those preemption disabling semantics, so we can't just take them away. Or am I missing something?
