Date: Tue, 10 Nov 2015 06:40:59 -0800 From: "Chris H" <bsd-lists@bsdforge.com> To: <freebsd-mips@freebsd.org> Subject: Re: CPU underload Message-ID: <aa4040f884770a0edf49e708e6aa0837@ultimatedns.net> In-Reply-To: <42B3546E-F0F5-4A66-AFF0-D16465343FF9@bsdimp.com> References: <56348063.3090508@grosbein.net> <563500FC.8020201@grosbein.net> <CAJ-Vmo=EpmG6OJxq_v_mqKMF48h_B3K7vKqnnaKAi3x1s-uaWQ@mail.gmail.com> <5635148B.2070307@grosbein.net> <CAJ-VmomzkG8ZB0h1Qc=Oeny2ZOzQg1UirUprM_gmMy64F5ZRYw@mail.gmail.com> <56351AA6.80903@grosbein.net> <CAJ-VmomLen5p7ELejU7QtC5CO2j8hydb_CvdOqQsfaaMAtmdkA@mail.gmail.com> <563523CA.3040207@grosbein.net> <CAJ-Vmonpd8R5C%2BNvhOGFD1okkkit990DV8c4Dm%2BLmpZ2uFfVkA@mail.gmail.com> <56367686.4090801@grosbein.net> <CAJ-VmomtJ9eKfAJYfn4e2S1xWN8-YHo0M0KH-9V=VjNBf6vVVA@mail.gmail.com> <563707A0.3040700@grosbein.net> <CANCZdfrB0hkjmTU-9NzimBv=X_h-=bF0D2azBxg=9B=kmitv7Q@mail.gmail.com> <56370E1D.3040801@grosbein.net> <CAJ-Vmo=0vOAq8db_GeLWmdXr7xJdzUh44ZZJrQ9vVdpvzT9hiQ@mail.gmail.com> <563F5630.2000407@grosbein.net> <CAJ-Vmon8_kHeg3FOzK6T8amzF=-0ia0-Hb1ve2zZoEdgxrHO8g@mail.gmail.com> <563F938B.3070707@grosbein.net> <CAJ-Vmon=GwJhUaoS=AH5iOzEAdUUEcCz9%2BW6jdPq3h1TyXZ_3A@mail.gmail.com> <1447090771.91534.477.camel@freebsd.org> <5640DB0E.8010005@grosbein.net> <1447091207.91534.481.camel@freebsd.org>, <42B3546E-F0F5-4A66-AFF0-D16465343FF9@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 Nov 2015 20:09:30 -0700 Warner Losh <imp@bsdimp.com> wrote > > On Nov 9, 2015, at 10:46 AM, Ian Lepore <ian@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aa4040f884770a0edf49e708e6aa0837>