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