Date: Sun, 21 Jun 2009 17:55:07 +0200 From: Attilio Rao <attilio@freebsd.org> To: Marius Strobl <marius@alchemy.franken.de> Cc: arch@freebsd.org, Peter Grehan <grehan@freebsd.org> Subject: Re: Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed Message-ID: <3bbf2fe10906210855r6c98568aj7bcc9ec3e057ae01@mail.gmail.com> In-Reply-To: <20090621140312.GC71667@alchemy.franken.de> References: <alpine.BSF.2.00.0906032050220.981@desktop> <20090609201127.GA50903@alchemy.franken.de> <4A2F1148.9090706@freebsd.org> <alpine.BSF.2.00.0906171231540.1025@desktop> <20090621140312.GC71667@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/6/21 Marius Strobl <marius@alchemy.franken.de>: > On Wed, Jun 17, 2009 at 12:55:52PM -1000, Jeff Roberson wrote: >> >> On Tue, 9 Jun 2009, Peter Grehan wrote: >> >> >>As for sparc64 allocating the storage for the dynamic area >> >>from end probably isn't a good idea as the pmap code assumes >> >>that the range from KERNBASE to end is covered by the pages >> >>allocated by and locked into the TLB for the kernel by the >> >>loader >> > >> >Ditto for ppc. It's possible to get the additional space from within or >> >after return from pmap_bootstrap() (like thread0's kstack, or the msgbuf). >> >> http://people.freebsd.org/~jeff/dpcpu.diff >> >> I have updated this patch based on feedback relating to various >> architectures md code. I tried to model most architectures after the way >> msgbuf memory was taken. I have no capacity to test anything other than >> i386 and amd64. ARM is reported to work with one minor diff. Apparently >> sparc64 worked with the earlier diff but this should be cleaner. If >> anyone can report back on sparc64, mips, or powerpc, I'd appreciate it. >> > > The earlier patch worked on sparc64 as long as the kernel > happened to leave enough room in the last 4MB page allocated > for it. > The new version unfortunately doesn't compile on sparc64 as > pmap_bootstrap_alloc() is static to its pmap.c (I think it > should also stay that way). Also the memory allocated with > it isn't safe to be used before we've taken over the trap > table. A kernel built with the sparc64 bits replaced with > the following patch boots fine: > http://people.freebsd.org/~marius/sparc64_dpcpu.diff > Do you have some simple test case for DPCPU which can be > used to verify that it actually works? I can suggest to switch pc_rm_queue of rmlocks in pcpu to be used as dynamic. It should not be difficult at all. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10906210855r6c98568aj7bcc9ec3e057ae01>