Date: Sun, 26 Jan 2014 18:06:22 -0700 From: Warner Losh <imp@bsdimp.com> To: Juli Mallett <jmallett@FreeBSD.org> Cc: "freebsd-mips@FreeBSD.org" <freebsd-mips@freebsd.org> Subject: Re: More trapframe panics Message-ID: <B20276B8-9753-4CA9-8DD5-060EB43F7823@bsdimp.com> In-Reply-To: <CACVs6=-V4jZeTUd_ncWUDKx3a6RX773nkqbqtDaQOvoX9edoLg@mail.gmail.com> References: <52E42A1B.3040907@rewt.org.uk> <CACVs6=--Qy_8poWdHdCXYKqkO22=dvHhW8=Uma8kLR%2BhCoZDxw@mail.gmail.com> <52E524BD.7090106@rlwinm.de> <CACVs6=-_N8aPEeFT5P8aTr1hkpmBWGwCt930wsGzg4YHxr8VKg@mail.gmail.com> <453F8F8F-41E5-4640-9683-5A8553AB0822@bsdimp.com> <CACVs6=-V4jZeTUd_ncWUDKx3a6RX773nkqbqtDaQOvoX9edoLg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Yea, I'm aware of the issues. I was hoping for a quick patch to make my = Cavium machines better since I know this is an optional feature of the = R4k spec. At the time I had my head wrapped around this, it seemed like = a faster path, but there were snags in non-uniform page sizes and alias = avoidance that make make this untenable anyway... Warner On Jan 26, 2014, at 4:30 PM, Juli Mallett wrote: > Robert Watson and someone else (IIRC) discouraged going this route as = some CPUs do not actually support every PageMask value specified for the = R4K, so it would turn into an implementation/maintenance nightmare. = Being able to fill an arbitrary number of TLB entries with kernel stack = seems just better, anyway, for, I dunno, the person who wants to run = Python in the kernel or something :) >=20 >=20 > On Sun, Jan 26, 2014 at 10:54 AM, Warner Losh <imp@bsdimp.com> wrote: >=20 > On Jan 26, 2014, at 9:04 AM, Juli Mallett wrote: >=20 > > On Sun, Jan 26, 2014 at 7:07 AM, Jan Bramkamp <crest@rlwinm.de> = wrote: > >> > >> Would increasing KSTACK_PAGES from two to three or four help? What = are > >> the trade-offs involved in choosing KSTACK_PAGES for something like = the > >> EdgeMax Lite? > > > > > > That's exactly what needs to happen in all 64-bit MIPS kernels. = Unlike > > some other architectures, KSTACK_PAGES cannot simply be increased, > > however. All of the code which handles loading the kernel stack and > > keeping it mapped, etc., assumes that it takes up exactly one TLB = entry, > > i.e. 2 pages. One could simply double KSTACK_PAGES for 64-bit = builds and > > modify the code to support the case of 2 or 4 pages, which would = keep the > > code as gross as it is today and not buy much flexibility, but might = be > > worthwhile as a short-term fix. Being able to support arbitrary = values of > > KSTACK_PAGES (or at least arbitrary multiples of 2 up to the maximum = number > > of wired TLB entries times 2) would be better. >=20 > I hacked together a kludge that quadrupled this by going to the next = larger page size for stack pages in the TLB, but hit something ugly when = I did that... But I've lost that code, so maybe I should try again to = see if I'm more clever the second time. >=20 > This is one of the things that makes it hard to have a nice native = build server on mips64... >=20 > Warner >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B20276B8-9753-4CA9-8DD5-060EB43F7823>