On 01/07/2013 12:47, Oleksandr Tymoshenko wrote: > On 12/27/2012 6:46 PM, Oleksandr Tymoshenko wrote: >> On 12/18/2012 1:59 AM, Alan Cox wrote: >>> On 12/17/2012 23:40, Oleksandr Tymoshenko wrote: >>>> On 2012-12-08, at 1:21 PM, Alan Cox <a...@rice.edu> wrote: >>>> >>>>> On 12/08/2012 14:32, Andre Oppermann wrote: >>>> .. skipped .. >>>> >>>>>> The trouble seems to come from NSFBUFS which is (512 + maxusers * >>>>>> 16) >>>>>> resulting in a kernel map of (512 + 400 * 16) * PAGE_SIZE = >>>>>> 27MB. This >>>>>> seem to be pushing it with the smaller ARM kmap layout. >>>>>> >>>>>> Does it boot and run when you set the tunable kern.ipc.nsfbufs=3500? >>>>>> >>>>>> ARM does have a direct map mode as well which doesn't require the >>>>>> allocation >>>>>> of sfbufs. I'm not sure which other problems that approach has. >>>>>> >>>>> Only a few (3?) platforms use it. It reduces the size of the user >>>>> address space, and translation between physical addresses and >>>>> direct map >>>>> addresses is not computationally trivial as it is on other >>>>> architectures, e.g., amd64, ia64. However, it does try to use large >>>>> page mappings. >>>>> >>>>> >>>>>> Hopefully alc@ (added to cc) can answer that and also why the >>>>>> kmap of >>>>>> 27MB >>>>>> manages to wrench the ARM kernel. >>>>>> >>>>> Arm does not define caps on either the buffer map size (param.h) >>>>> or the >>>>> kmem map size (vmparam.h). It would probably make sense to copy >>>>> these >>>>> definitions from i386. >>>> Adding caps didn't help. I did some digging and found out that >>>> although address range >>>> 0xc0000000 .. 0xffffffff is indeed valid for ARM in general actual >>>> KVA space varies for >>>> each specific hardware platform. This "real" KVA is defined by >>>> <virtual_avail, virtual_end> >>>> pair and ifI use them instead of <VM_MIN_KERNEL_ADDRESS, >>>> VM_MAX_KERNEL_ADDRESS> >>>> in init_param2 function my pandaboard successfully boots. Since >>>> former pair is used for defining >>>> kernel_map boundaries I believe it should be used for auto tuning >>>> as well. >>> >>> That makes sense. However, "virtual_avail" isn't the start of the >>> kernel address space. The kernel map always starts at >>> VM_MIN_KERNEL_ADDRESS. (See kmem_init().) "virtual_avail" represents >>> the next unallocated virtual address in the kernel address space at an >>> early point in initialization. "virtual_avail" and "virtual_end" >>> aren't >>> used after that, or outside the VM system. Please use >>> vm_map_min(kernel_map) and vm_map_max(kernel_map) instead. >> >> I checked: kernel_map is not available (NULL) at this point. So we >> can't use it to >> determine real KVA size. Closest thing we can get is >> virtual_avail/virtual_end pair. >> >> Andre, could you approve attached patch for commit or suggest better >> solution? > > Any update on this one? Can I proceed with commit? >
Sorry, I've been away from my e-mail since the 30th, and I'm now in the process of getting caught up. Give me a day or so to look at this. Alan _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
