From owner-freebsd-mips@FreeBSD.ORG Mon Jan 27 01:06:31 2014 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 721CA681 for ; Mon, 27 Jan 2014 01:06:31 +0000 (UTC) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 337631EB3 for ; Mon, 27 Jan 2014 01:06:30 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id at1so5186281iec.11 for ; Sun, 26 Jan 2014 17:06:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=P4vZgWgUM+v046MfV1J2L+Ux0QHBK1O8ktbcMKCZ+Zo=; b=aqW/68dVnFxrsYp4dmAuq9kCnIXTmhvF9Yb1nprwaVVHSitmuxWx6vrKyJoMNDcDla 0eu0+hKvfU40GCJSXMoX54jXlLdzpC00exuLRwIJjFIaZ+BV9giahaDyDiJC++/90P+z Dbg/vLiW75xmlEQ62zpCMVbg25E3Pxi7ChwZ1Vy73PphhwQ+lLvRLiOVjz+X9yppHZvf /u88hQN4nKLEpQOSmvioueS/qFTOAlbErQLbWLzakWzWLLUs3XDBxmzLD+5yrcxRtFQu wEaVElplIdEzqmveey6a2oCjPxBfjryZb9OQJJ8Fnr7emdow37wJrG7UjVSFDfXxn0MW plIA== X-Gm-Message-State: ALoCoQn5T3XUITd/8kYsxQ+/dkZTEP+9kaeR9LBFPXjH3oSmzC+jwBcdZieXwajsWPJ6nrYjV0Ei X-Received: by 10.51.17.71 with SMTP id gc7mr15023987igd.12.1390784784143; Sun, 26 Jan 2014 17:06:24 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id qb3sm37366780igb.7.2014.01.26.17.06.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Jan 2014 17:06:23 -0800 (PST) Sender: Warner Losh Subject: Re: More trapframe panics Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 26 Jan 2014 18:06:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52E42A1B.3040907@rewt.org.uk> <52E524BD.7090106@rlwinm.de> <453F8F8F-41E5-4640-9683-5A8553AB0822@bsdimp.com> To: Juli Mallett X-Mailer: Apple Mail (2.1085) Cc: "freebsd-mips@FreeBSD.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 01:06:31 -0000 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 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 = 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