From owner-freebsd-mips@freebsd.org Tue Nov 10 14:54:23 2015 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79217A2A25A for ; Tue, 10 Nov 2015 14:54:23 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 41FD81DDD for ; Tue, 10 Nov 2015 14:54:23 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id tAAEerHm034780 for ; Tue, 10 Nov 2015 06:40:59 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <42B3546E-F0F5-4A66-AFF0-D16465343FF9@bsdimp.com> References: <56348063.3090508@grosbein.net> <563500FC.8020201@grosbein.net> <5635148B.2070307@grosbein.net> <56351AA6.80903@grosbein.net> <563523CA.3040207@grosbein.net> <56367686.4090801@grosbein.net> <563707A0.3040700@grosbein.net> <56370E1D.3040801@grosbein.net> <563F5630.2000407@grosbein.net> <563F938B.3070707@grosbein.net> <1447090771.91534.477.camel@freebsd.org> <5640DB0E.8010005@grosbein.net> <1447091207.91534.481.camel@freebsd.org>, <42B3546E-F0F5-4A66-AFF0-D16465343FF9@bsdimp.com> From: "Chris H" Subject: Re: CPU underload Date: Tue, 10 Nov 2015 06:40:59 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 14:54:23 -0000 On Mon, 9 Nov 2015 20:09:30 -0700 Warner Losh wrote > > On Nov 9, 2015, at 10:46 AM, Ian Lepore wrote: > > > > On Tue, 2015-11-10 at 00:42 +0700, Eugene Grosbein wrote: > >> On 10.11.2015 00:39, Ian Lepore wrote: > >>> On Sun, 2015-11-08 at 11:23 -0800, Adrian Chadd wrote: > >>>> ok, what's the l1 cache size reported at boot up? > >>>> > >>>> I think I may just bump them all to 64. > >>> > >>> 64 is not some kind of magic panacea. The value needs to be set to > >>> the > >>> cache line size for the runtime platform. If the right value is > >>> 32, > >>> then setting it to 64 will just waste memory. > > If we ever have a universal kernel, 64 could run on either 32 or > 64 byte cache lines. Since we don’t, this is largely correct. It was > mostly a quick and easy to test suggestion, it doesn’t matter since: > > >>>> L1 d-cache: 4 ways of 256 sets, 32 bytes per line > > >> Is it for instruction cache or for data cache? > > > > Only the data cache size matters for USB_HOST_ALIGN. > > Since we’re flushing the data cache, and we don’t want the > device visible part of the USB buffers to share a cache line > with other data for the host to use about the device. Making > it too big doesn’t help, and costs memory. Making it too small > is fatal: usb simply won’t work. Pitty. Cause it seems like 48 might have been a nice compromise. :) > > Why we don’t have a panic when the cache line size is larger > than usb_host_align, and a warning when it is smaller is > beyond me... > > Warner