From owner-svn-src-all@freebsd.org Wed Dec 28 17:37:47 2016 Return-Path: Delivered-To: svn-src-all@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 20C0DC94D33; Wed, 28 Dec 2016 17:37:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F1A581904; Wed, 28 Dec 2016 17:37:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 0177410A74C; Wed, 28 Dec 2016 12:37:46 -0500 (EST) From: John Baldwin To: Adrian Chadd Cc: Alexander Kabaev , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Subject: Re: svn commit: r310650 - in head/sys/mips: include mips Date: Wed, 28 Dec 2016 09:30:17 -0800 Message-ID: <8608352.T4YV5SIEDd@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: <201612280255.uBS2tQeR045512@repo.freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 28 Dec 2016 12:37:46 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 17:37:47 -0000 On Tuesday, December 27, 2016 09:50:32 PM Adrian Chadd wrote: > hiya, >=20 > so I dug into the mips24k definition of this. It says this: >=20 > " > 3.4.3 Uncached accelerated writes > The 24K core permits memory regions to be marked as =E2=80=9Cuncached= > accelerated=E2=80=9D. This type of region is useful to hard- > ware which is =E2=80=9Cwrite only=E2=80=9D - perhaps video frame buff= ers, or some > other hardware stream. Sequential word stores in > such regions are gathered into cache-line-sized chunks, before being > written with a single burst cycle on the CPU > interface. > Such regions are uncached for read, and partial-word or > out-of-sequence writes have =E2=80=9Cunpredictable=E2=80=9D effects -= don=E2=80=99t > do them. The burst write is normally performed when software writes t= o > the last location in the memory block or does > an uncached-accelerated write to some other block; but it can also be= > triggered by a > sync instruction, a pref nudge, a matching load or any exception. If > the block is not completely written by the time it=E2=80=99s pushed o= ut, it > will be written using a series of doubleword or smaller write cycles > over the 24K core=E2=80=99s 64-bit memory interface. > " >=20 > So, question is - is our write combining page attribute in the VM > suitable for this? Is it defined as "only do full sequential word > writes"? Or do we risk having some other platform use it in a less > "don't do this" way and then MIPS is the one at fault again? :) The description of WC in the Intel SDM appears to be more forgiving. If you do out-of-sequence writes it won't "lose" the data, but there isn't a strong ordering of when the different regions of a cache line are finally written. Also, different WC store buffers may be written out-of-order (e.g. if you partially fill one line, then fully fill a second line, the second line may be written out, but the first one will= be held for a bit to see if it will be fully filled). However, you never lose the data, and the last thing written will eventually end up being written to the bus. --=20 John Baldwin