From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 22:06:08 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94DE31065676 for ; Tue, 28 Apr 2009 22:06:08 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (tokyo01.jp.mail.your.org [204.9.54.5]) by mx1.freebsd.org (Postfix) with ESMTP id 51C9C8FC15 for ; Tue, 28 Apr 2009 22:06:08 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (localhost.your.org [127.0.0.1]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id 298FF2AD55A5; Tue, 28 Apr 2009 21:48:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=dragondata.com; h=cc :message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references; s=selector1; bh=+tGGjWNsBnraHZiNnl1w8KoGBXI=; b=fuWm2WN6uNwhdW+ b2MEn0Qtg/k0If5fHgwbWoQIvgNWrgVy70EBz3tU3JqVkWwRbPvz0hkq6V91Wm/M X2TL3M1Y0gocceBAKcb0T2FsanjzolPW/PuVKenBCviRhhIYjuZq3oa3N6ePSBFe kop7cuuOYDwwW79GAOPtFzWHg1IY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=dragondata.com; h=cc:message-id :from:to:in-reply-to:content-type:content-transfer-encoding :mime-version:subject:date:references; q=dns; s=selector1; b=c8x NasUhGRVSVDxtb//wcL2z6FqAZhc/MawfQvGnGv7tB1fVN/rj9epAgVMD6bKCJLe M+ewJ5mH3rsgosqLVkcJCBRM2ijlXtW5uwoXNCke24UFyknt2K9quosHZwFmvXA6 SRI4eo+d5gHpOhjEmAEaJ7bkGOTT4uhJXTFtp2R4= Received: from mail.your.org (server2-a.your.org [216.14.97.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by tokyo01.jp.mail.your.org (Postfix) with ESMTPS id E481C2AD555A; Tue, 28 Apr 2009 21:48:37 +0000 (UTC) Received: from [216.14.99.244] (unknown [216.14.99.244]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTPSA id 0A4282C9011; Tue, 28 Apr 2009 21:48:35 +0000 (UTC) Message-Id: From: Kevin Day To: "Julian Bangert" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 16:48:35 -0500 References: X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Tue, 28 Apr 2009 22:29:42 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 22:06:09 -0000 On Apr 28, 2009, at 3:19 PM, Julian Bangert wrote: > Hello, > > I am currently trying to work a bit on the remaining "missing > feature" that NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRequests > or a back post in this ML) - the improved mmap system call. > For now, I am trying to extend the current system call and > implementation to add cache control ( the type of memory caching > used) . This feature inherently is very architecture specific- but > it can lead to enormous performance improvements for memmapped > devices ( useful for drivers, etc). I would do this at the user site > by adding 3 flags to the mmap system call (MEM_CACHE__ATTR1 to > MEM_CACHE__ATTR3 ) which are a single octal digit corresponding to > the various caching options ( like Uncacheable,Write Combining, > etc... ) with the same numbers as the PAT_* macros from i386/include/ > specialreg.h except that the value 0 ( PAT_UNCACHEABLE ) is replaced > with value 2 ( undefined), whereas value 0 ( all 3 flags cleared) is > assigned the meaning "feature not used, use default cache control". > For each cache behaviour there would of course also be a macro > expanding to the rigth combination of these flags for enhanced > useability. > > The mmap system call would, if any of these flags are set, decode > them and get a corresponding PAT_* value, perform the mapping and > then call into the pmap module to modify the cache attributes for > every page. Have you looked at mem(4) yet? Several architectures allow attributes to be associated with ranges of physical memory. These attributes can be manipulated via ioctl() calls performed on /dev/mem. Declarations and data types are to be found in . The specific attributes, and number of programmable ranges may vary between architectures. The full set of supported attributes is: MDF_UNCACHEABLE The region is not cached. MDF_WRITECOMBINE Writes to the region may be combined or performed out of order. MDF_WRITETHROUGH Writes to the region are committed synchronously. MDF_WRITEBACK Writes to the region are committed asynchronously. MDF_WRITEPROTECT The region cannot be written to. This requires knowledge of the physical addresses, but I believe that's probably already necessary for what it sounds like you're trying to accomplish. Back in the FreeBSD-3.0 days, I was writing a custom driver for an AGP graphics controller, and setting the MTRR flags for the exposed buffer was a definite improvement (200-1200% faster in most cases). -- Kevin