On 2019-07-02 6:59 p.m., Jason Gunthorpe wrote: > On Wed, Jul 03, 2019 at 12:49:12AM +0200, Christoph Hellwig wrote: >> On Tue, Jul 02, 2019 at 07:53:23PM +0000, Jason Gunthorpe wrote: >>>> I'm sending this out now since we are updating many of the HMM APIs >>>> and I think it will be useful. >>> This make so much sense, I'd like to apply this in hmm.git, is there >>> any objection? >> As this creates a somewhat hairy conflict for amdgpu, wouldn't it be >> a better idea to wait a bit and apply it first thing for next merge >> window? > My thinking is that AMD GPU already has a monster conflict from this: > > int hmm_range_register(struct hmm_range *range, > - struct mm_struct *mm, > + struct hmm_mirror *mirror, > unsigned long start, > unsigned long end, > unsigned page_shift); > > So, depending on how that is resolved we might want to do both API > changes at once. I just sent out a fix for the hmm_mirror API change. > > Or we may have to revert the above change at this late date. > > Waiting for AMDGPU team to discuss what process they want to use. Yeah, I'm wondering what the process is myself. With HMM and driver development happening on different branches these kinds of API changes are painful. There seems to be a built-in assumption in the current process, that code flows mostly in one direction amd-staging-drm-next -> drm-next -> linux-next -> linux. That assumption is broken with HMM code evolving rapidly in both amdgpu and mm. If we want to continue developing HMM driver changes in amd-staging-drm-next, we'll need to synchronize with hmm.git more frequently, both ways. I believe part of the problem is, that there is a fairly long lead-time from getting changes from amd-staging-drm-next into linux-next, as they are held for one release cycle in drm-next. Pushing HMM-related changes through drm-fixes may offer a kind of shortcut. Philip and my latest fixup is just bypassing drm-next completely and going straight into linux-next, though. Regards, Felix > > Jason
