Re: Resecting "options UVM_HOTPLUG"

["Mathew\, Cherry G.*" <c%bow.st@localhost>]

>>>>> Santhosh Raju <fox%netbsd.org@localhost> writes:

    > On Fri, Dec 1, 2023 at 6:42 AM Mathew Cherry G. <c%bow.st@localhost> wrote:
    >> 
    >> Hi,
    >> 
    >> After some discussion with Jason, and re-reading the code and its
    >> current state in code, I've come to the conclusion that it's in
    >> the interest of brevity to remove everything in sys/kern/ and
    >> sys/uvm/ which implement the "dynamic" part of uvm_hotplug(9).
    >> 
    >> The top two reasons for this in my mind are:
    >> 
    >> 1) There are no current users of the uvm_hotplug(9) KPI -
    >> balloon(9) uses it, but the unplug is unstable (wasn't able to
    >> debug this) and is thus disabled by default.
    >> 
    >> 2) In order to do unplug without a balloon(9) like mechanism (eg:
    >> on native), there's a lot more state management code needed
    >> within uvm(9) - to make sure that RAM segments being unplugged
    >> have no machine references (eg: pmap related, pointers from
    >> inactive page tables, TLB pointers, etc. etc. )
    >> 
    >> This is a lot of per-architecture work, and there doesn't seem to
    >> be much demand for this feature (at least I haven't seen any
    >> comment related to this as a usecase).
    >> 

    > I agree with these points and if the "dynamic" part is not being
    > used.  I am assuming we are not completely removing the
    > UVM_HOTPLUG option?

That's right - the static code is required for normal functioning of
uvm(9)

    >> I believe that the project has had three useful purposes:
    >> 
    >> 1) Demonstrated NetBSD code discipline - such a core part of the
    >> kernel code was developed entirely in userspace prior to
    >> integration - and due to the cross-compilable toolchain - it was
    >> done on Windows by fox@!
    >> 
    >> 2) The re-org forced better modularisation in the relevant
    >> uvm/uvm_*.[hc] - ensuring even cleaner interfaces.
    >> 
    >> 3) Demonstrated how TDD can reduce the pain of software dev. See:
    >> https://www.netbsd.org/gallery/presentations/santhosh/2017_AsiaBSDCon/ABC2017-P8B-uvm_hotplug-paper.pdf
    >> 
    >> 
    >> If there's no specific objection to this I'll be working with
    >> Jason to help make this is as painless as possible.
    >> 

    > I am happy to offer any assistance needed to remove the related
    > code if needed since I did work on the tests part of it.

That would be great - in fact, this is probably a great opportunity to
rig the tests (src/tests/sys/uvm/) into the build system.

Many Thanks,
-- 
MattC/(~cherry)