uma_small_alloc from direct mapped memory.

[Jayachandran C.]

On Mon, Dec 6, 2010 at 4:28 PM, Juli Mallett <jmallett at freebsd.org> wrote:
> On Mon, Dec 6, 2010 at 02:25, Jayachandran C. <c.jayachandran at gmail.com> wrote:
>> I was planning to merge these changes. Now that the XLR platform code
>> changes and 8-STABLE merge is done - I hope to get some time to do the
>> rest of the n64 work. My rough todo list is :
>>
>> - 64bit PTEs which will give >4GB phys address,
>
> I'm very excited about that; on Octeon it will mean that we can
> participate in the networking/messaging subsystem from userland, which
> I know will be very valuable for a lot of applications.
>
>> - 32 bit compat in n64 (merge from /user/jmallett/octeon)
>
> You probably don't want to spend much time on those changes; they were
> incomplete and focused on n32-on-n64.  I know n32-on-n64 would be
> good, but is it your highest priority?  o32-on-n64 will be easy
> because it's just like on other architectures.  o32-on-n32 and
> n32-on-n64 require a complementary set of conditionals in the
> freebsd32 code to handle (in the former case) pointer size being
> unchanged and (in the latter case) register width being unchanged.  I
> think we actually need to consider alternate compilation strategies
> for the freebsd32 code, such as filling it with ifdefs and #including
> the source files with different definitions so we can include o32 and
> n32 compat together on n64 kernels.

o32 on n64 is probably the most useful one, but I haven't looked at it
in detail.  I thought I would merge your code first and then
understand what more is needed.

>> - Complete merge from /user/jmallett/octeon - UIO, sf buf
>
> Great :)
>
>> - DDB/KDB fixes for n32/n64.
>
> For what it's worth, DDB seems mostly complete on n64 these days, save
> for some issues in the trace code — I think we took the machdep ddb
> code from NetBSD and now that they support n32 and n64 I think we may
> just want to merge from them, no point duplicating that effort when
> the code is so crufty, complex and massive already.
>
> Maybe talk to bde@ or freebsd-arch@ or freebsd-hackers@ about the DDB
> changes required for n32 (and get someone to review the change to ufs
> to not use register_t where it mean uintptr_t / vm_offset_t) — some of
> the cleanups to be had there are good, but I think that there is some
> resistance to changing DDB just for n32.  I think it's a good idea,
> but I'm not sure e.g. whether it's better to adjust the DDB APIs that
> pass addresses to use vm_offset_t or uintptr_t, or to keep them
> passing register_t and to make code that takes addresses from
> registers (or register_ts) more careful about how it converts them,
> since probably other ABIs will come along where using an opaque
> register type as something that can be converted directly to a pointer
> is bad.  Perhaps what we really need are more debugger-specific types.
>
> Something that might be a worthwhile sell would be to continue to pass
> register_t in those APIs and to introduce a call (that can fail) to
> map a register_t to an address usable by the debugger, that way we can
> also do clever things to avoid page faults within the debugger, in
> addition to doing the necessary casts on n32.  That would benefit more
> than just MIPS.

There are fixes needed in n64 too. But as you said, to do n32
correctly would be a lot of trouble :)

>> - 16K pagesize (there were some patches from SoC, but it crashed for me)
>
> Do you want to support both 4K and 16K pages on all MIPS ABIs, or just
> n64, or make n64 always 16k and everything else always 4k?

I was thinking of a config option. The executables are already aligned
at 64K, so the userspace should not be a problem.  Last time this was
discussed, someone noted that there was issues in earlier FreeBSD
versions for large page sizes. I have the 16K patch booting, but the
userspace crashes a lot and I did not get enough time to debug that.

JC.