tech-kern archive

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

Re: Portmasters alert: was => Re: uvm physseg - put the lid on it.



>>>>> "Cherry" == Cherry G Mathew <cherry%zyx.in@localhost> writes:

>>>>> "Cherry" == Cherry G Mathew <cherry%zyx.in@localhost> writes:
    Cherry> Hi Everyone, Here's a patch to put the vm physseg stuff
    Cherry> behind bars.

    Cherry> I've made some pretty intrusive changes, esp. to the boot
    Cherry> time msgbuf stuff, so if portmasters could have a quick look
    Cherry> at this, I'll be able to go ahead and change the equivalents
    Cherry> on other ports.

    Cherry> I have a bunch of tests that actually test these functions
    Cherry> in userland via rump. It's pretty cool :-)

    Cherry> Ultimately, I want to change the backing implementation to
    Cherry> use an rb tree rather than a static array, so that the
    Cherry> plug/unplug is dynamic. Obviously, this patch is not any
    Cherry> attempt at an "API" - it's just code reorg, to make the next
    Cherry> steps easier.

    >> PS: Please reply everyone for public replies, since some on the
    >> Cc: list may not be subscribed to tech-kern@

    >> Hi Everyone,

    >> Thanks for the feedback to folks who sent them in.

    >> Here's some further patches. I've broken them out for your
    >> convenience:

    >> i) atf(7) tests for the new consolidated "API". These are with
    >> the caveat that they will change along with the implementation
    >> code, when the actual unplug API hits the road. Santhosh (Cc:ed)
    >> collaborated closely with me for these.

    >> ftp://ftp.netbsd.org/pub/NetBSD/misc/cherry/uvm_physmem/cvs.tests.sys.uvm.diff

    >> ii) uvm(9) changes. The #ifdef _KERNEL_OPT is required for the
    >> rump(9) testing code (see (ii) below:

    >> ftp://ftp.netbsd.org/pub/NetBSD/misc/cherry/uvm_physmem/cvs.sys.uvm.diff

    >> iii) port specific changes. I have only tested i386 and amd64. I
    >> have compiled all ports in these diffs.

    >> *Portmasters*, it would be immensely helpfull if you could test
    >> them on your respective ports please.

    >> ftp://ftp.netbsd.org/pub/NetBSD/misc/cherry/uvm_physmem/cvs.sys.arch.diff

    >> Please, no KNF comments yet - I will clean up in a final pass -
    >> I'm really looking for testing and reporting on function (or
    >> breakage!)

    >> I will aim to cut a branch in CVS RSN.

    >> Many Thanks, -- ~cherry

    Cherry> Have updated the patches with some more stuff:

    Cherry> i) Reverted to the current (imho broken) use of
    Cherry> start/avail_start,end/avail_end in boot time segment
    Cherry> "stealing".  This was to minimise divergence with the
    Cherry> current implementation.

    Cherry> ii) Changed the assumption of "handles" to memory segments
    Cherry> from mutable to immutable. A corresponding test was added
    Cherry> (which fails). This is in preparation for changing from the
    Cherry> current array based implementation to a more dynamic
    Cherry> implementation where the handle pointing to backing nodes
    Cherry> will be immutable.

    Cherry> iii) Introduced specific error constants for specific error
    Cherry> conditions in segment node handle traversal.

    Cherry> iv) Fixed a bug introduced in calculating the number of
    Cherry> backing struct vm_page;s allocated per segment.


    Cherry> I've changed my mind about cutting a new branch. The rbtree
    Cherry> backed node management code is wip (it passes all the
    Cherry> userland tests, but needs boot time memory alloc sorted ). I
    Cherry> will cut the new branch with the rbtree code. This set of
    Cherry> patches will have tests which will very likely remain
    Cherry> unchanged wrt the newer implementation with rbtrees.

    Cherry> Santhosh is now working on managing backing pgs[] in the
    Cherry> case of unplug(). This may involve some changes to
    Cherry> extent(9). We're gravitating towards using extent(9) instead
    Cherry> of vmem(9) since it provides a much more flexible backend
    Cherry> memory allocation (the caveat of alloc on fragmenting
    Cherry> free()s can be addressed by using pool(9), iiuc right now -
    Cherry> still under design)

    Cherry> Those are my unfinished thoughts for now.

Updated with the rbtree implementation for segment nodes (instead of an
array of segments). Thank you Santhosh (Cc:ed) for a tight, simple
implementation with excellent testing coverage - the native build booted
straight off with no debugging required.

I've added a little hack for boot time, which uses a static array
identical to the original implementation only at boot time. Once kmem(9)
is up, it uses regular kernel memory. free()s back to the array are
ignored (and therefore leaky) - this is tested in the test cases.

I've also updated all ports with the init call uvm_physmem_init(), with
absolutely no idea about the appropriateness of its location.

ftp://ftp.netbsd.org/pub/NetBSD/misc/cherry/uvm_physmem

Please note that the diffs themselves are versioned via RCS - so you can
look at previous versions of the diffs, if you like.

Have fun!

PS: What I'd love to have is people trying these patches on ports other
than amd64/i386 and reporting back on breakage etc. (or fixing things!)

Next stop, seg->pgs[] backing management. This is a bit trickier (as
mentioned in my previous email).


Many Thanks,
-- 
~cherry


Home | Main Index | Thread Index | Old Index