Re: + mm-thp-always-specify-disabled-vmas-as-nh-in-smaps.patch added to -mm tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon 21-01-19 21:00:29, Cyrill Gorcunov wrote:
> On Mon, Jan 21, 2019 at 11:21:44AM +0100, Michal Hocko wrote:
> ...
> > > 
> > > The patch from David obviously breaks CRIU, and I can't see a nice solution
> > > that will work for everybody.
> > > 
> > > Of course we could add something like 'NH' to /proc/pid/smaps so that 'nh'
> > > will work as David's userspace is expecting and 'NH' will represent the
> > > state of VmFlags. This is hackish and ugly, though.
> > > 
> > > In any case, if David's patch is not reverted CRIU needs some way to know
> > > if VMA has VM_NOHUGEPAGE set.
> > 
> > Hmm, there doesn't seem to be any follow up here and the patch is still
> > in the mmotm tree AFAICS in mainline-urgent section. I thought it was
> > clarified that the patch will break an existing userspace that relies on
> > the documented semantic.
> > 
> > While it is unfortunate that the use case mentioned by David got broken
> > we have provided a long term sustainable which is much better than
> > relying on an undocumented side effect of the prctl implementation at
> > the time.
> > 
> > So can we make a decision on this finally please?
> 
> As to me David's userspace application could use /proc/$pid/status
> to fetch precise THP state. And the patch in mm queue simply breaks
> others userspace thus should be reverted.

7635d9cbe832 ("mm, thp, proc: report THP eligibility for each vma") will
provide even more detailed information because it displays THP
eligibility per VMA so you do not have to check all other conditions
that control THP.

-- 
Michal Hocko
SUSE Labs




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux