>>>>> Santhosh Raju <f...@netbsd.org> writes:
> On Fri, Dec 1, 2023 at 6:42 AM Mathew Cherry G. <c...@bow.st> 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)
