Hi Balbir, On Sat, Oct 27, 2018 at 09:21:02PM +1100, Balbir Singh wrote: > On Wed, Oct 24, 2018 at 07:13:50PM -0700, Joel Fernandes wrote: > > On Wed, Oct 24, 2018 at 10:57:33PM +1100, Balbir Singh wrote: > > [...] > > > > > + pmd_t pmd; > > > > > + > > > > > + new_ptl = pmd_lockptr(mm, new_pmd); > > > > > > > > > Looks like this is largely inspired by move_huge_pmd(), I guess a lot of > > > the code applies, why not just reuse as much as possible? The same comments > > > w.r.t mmap_sem helping protect against lock order issues applies as well. > > > > I thought about this and when I looked into it, it seemed there are subtle > > differences that make such sharing not worth it (or not possible). > > > > Could you elaborate on them? The move_huge_page function is defined only for CONFIG_TRANSPARENT_HUGEPAGE so we cannot reuse it to begin with, since we have it disabled on our systems. I am not sure if it is a good idea to split that out and refactor it for reuse especially since our case is quite simple compared to huge pages. There are also a couple of subtle differences between the move_normal_pmd and the move_huge_pmd. Atleast 2 of them are: 1. We don't concern ourself with the PMD dirty bit, since the pages being moved are normal pages and at the soft-dirty bit accounting is at the PTE level, since we are not moving PTEs, we don't need to do that. 2. The locking is simpler as Kirill pointed, pmd_lock cannot fail however __pmd_trans_huge_lock can. I feel it is not super useful to refactor move_huge_pmd to support our case especially since move_normal_pmd is quite small, so IMHO the benefit of code reuse isn't there very much. Do let me know your thoughts and thanks for your interest in this. thanks, - Joel
