On Sat, Oct 27, 2018 at 12:39:17PM -0700, Joel Fernandes wrote:
Hi Balbir,
On Sat, Oct 27, 2018 at 09:21:02PM +1100, Balbir Singh wrote:
quoted
On Wed, Oct 24, 2018 at 07:13:50PM -0700, Joel Fernandes wrote:
quoted
On Wed, Oct 24, 2018 at 10:57:33PM +1100, Balbir Singh wrote:
[...]
quoted
quoted
quoted
+ 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.
My big concern is that any bug fixes will need to monitor both paths.
Do you see a big overhead in checking the soft dirty bit? The locking is
a little different. Having said that, I am not strictly opposed to the
extra code, just concerned about missing fixes/updates as we find them.
Do let me know your thoughts and thanks for your interest in this.
Balbir Singh.