On 12/21/18 10:27 AM, David Rientjes wrote: > On Thu, 20 Dec 2018, Andrew Morton wrote: > >>>> The patch titled >>>> Subject: mm, thp: always specify disabled vmas as nh in smaps >>>> has been added to the -mm tree. Its filename is >>>> mm-thp-always-specify-disabled-vmas-as-nh-in-smaps.patch >>>> >>>> This patch should soon appear at >>>> http://ozlabs.org/~akpm/mmots/broken-out/mm-thp-always-specify-disabled-vmas-as-nh-in-smaps.patch >>>> and later at >>>> http://ozlabs.org/~akpm/mmotm/broken-out/mm-thp-always-specify-disabled-vmas-as-nh-in-smaps.patch >>>> >>>> Before you just go and hit "reply", please: >>>> a) Consider who else should be cc'ed >>>> b) Prefer to cc a suitable mailing list as well >>>> c) Ideally: find the original patch on the mailing list and do a >>>> reply-to-all to that, adding suitable additional cc's >>>> >>>> *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** >>>> >>>> The -mm tree is included into linux-next and is updated >>>> there every 3-4 working days >>>> >>>> ------------------------------------------------------ >>>> From: David Rientjes <rientjes@xxxxxxxxxx> >>>> Subject: mm, thp: always specify disabled vmas as nh in smaps >>>> >>> >>> I notice that this wasn't pushed for 4.20, when can we anticipate that >>> this patch is merged upstream to fix our userspace statistics gathering? >> >> It wasn't very popular but I suppose we should do this. The offending >> commit is 18 months old so it doesn't seem terribly urgent. >> >> Why no cc:stable? >> > > I agree that it isn't terribly urgent, we can simply blacklist the kernel > versions where the problem occurs. If others complain I would agree it > warrants backport to stable, but the stable rules specifically say it must > affect more than one user? I don't think it would be best to guess. But > when userspace was implemented to determine thp eligibility using the only > possible means to do so, it seems important to not break that. We caught > that it broke us, hence the patch. There's also Michal's series to expand THP eligibility reporting. If it would be feasible for you to switch to that implementation in your userspace, and perhaps only locally and temporarily add your patch to your currently used older kernel versions, then the benefit would be one less obscure exception in the kernel API. If it's infeasible then I don't think further discussion is needed and we should abide by the do-not-break-userspace rule. I'd say stable is up to you as well in this case, whether you're going to consume the fixed stable versions. > If there are concerns about a patch not being very popular, I think it > would be best to discuss this rather than missing a release cycle. The > premise here is that we don't break userspace, as the offending commit > broke us. > > Thanks. >
