On 17.01.2012, at 12:31, Paul Mackerras wrote: > On Tue, Jan 17, 2012 at 10:27:26AM +0100, Alexander Graf wrote: > >> The thing I was getting at was not the map during the lifetime, but >> the map during registration. Currently we have: >> >> 1) Set VPA to x >> 2) Assign feature y to VPA >> 3) Use VPA >> >> 1 and 2 are the slow path, 3 occurs more frequently. So we want 3 to >> be fast. 1 and 2 don't matter that much wrt performance. >> >> You are currently mapping the VPA at /, which gets you into this >> map/unmap mess trying to free the previous mapping. If you moved the >> map to step 2 and only stored the GPA at step 1, all map+unmap >> operations except for final unmaps would be in one spot, so you >> wouldn't need to construct this big complex state machine. > > That might simplify things - I'll try it and see. The worry with > doing the map/pin at 2 is that if anything goes wrong we no longer > have the opportunity to return an error for the H_REGISTER_VPA call, > so I'll have to at least do some checking in 1, leading to possibly > more code overall. Well, then map and unmap it in step 1 and map it in step 2 again. We're in the slow path so performance isn't critical. Readability and maintainability however are :) Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
