From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 20:32:13 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 04C9C106566C for ; Tue, 28 Apr 2009 20:32:13 +0000 (UTC) (envelope-from julidaoc@online.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.freebsd.org (Postfix) with ESMTP id 727248FC14 for ; Tue, 28 Apr 2009 20:32:12 +0000 (UTC) (envelope-from julidaoc@online.de) Received: from server2go (p54A12E3D.dip0.t-ipconnect.de [84.161.46.61]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MKv5w-1LytmB02aT-0001mT; Tue, 28 Apr 2009 22:19:35 +0200 Date: Tue, 28 Apr 2009 22:19:34 +0200 To: freebsd-hackers@freebsd.org From: "Julian Bangert" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: User-Agent: Opera Mail/9.64 (Linux) X-Provags-ID: V01U2FsdGVkX18wWrayBFLchXyr2saVeql9GzBDgWVe2tx4843 H/Wzdv51n0O/lVGgC5gaKgJ+dXtcZJmFvFgWBVXOT2e/I46o8Z uyRrnhCunTibY14z+WyrpInbzL2xaon X-Mailman-Approved-At: Tue, 28 Apr 2009 20:47:06 +0000 Subject: 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 20:32:13 -0000 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. My first question is if there is a more elegant way of solving that - the 3 flags would be architecture specific ( they could be used for other things on other architectures though if need be ) and I do not know the policy on architecture specific syscall flags, therefore I appreciate any input. The second question goes to all those great VM/pmap gurus out there: As far as I understand, at the moment the pmap_change_attr can only cange the cache flags for kernel pages. Is there a particular reason why this function might not be adapted/extended to userspace mappings? If not, I would either add a new function to iterate over all pages and set cache flags for a particular region or add a new member (possibly just add the 3 flags again ? ) to the md part of vm_page_t. Or one could just keep track and return errors as soon as someone tries to map a memory region ( cache-customized mapping is usually done to device memory ) already mapped with different cache behaviour. I thank you for your assistance & happy coding, --Julian Bangert