From owner-freebsd-arm@FreeBSD.ORG Thu Dec 20 00:41:36 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 044F07D for ; Thu, 20 Dec 2012 00:41:36 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id BDB268FC13 for ; Thu, 20 Dec 2012 00:41:35 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBK0fSQf057028 for ; Wed, 19 Dec 2012 17:41:28 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBK0fPo7065942 for ; Wed, 19 Dec 2012 17:41:25 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: nand performance From: Ian Lepore To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Dec 2012 17:41:25 -0700 Message-ID: <1355964085.1198.255.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 00:41:36 -0000 I've been working to get nandfs going on a low-end Atmel arm system. Performance is horrible. Last weekend I got my nand-based DreamPlug unbricked and got nandfs working on it too. Performance is horrible. By that I'm referring not to the slow nature of the nand chips themselves, but to the fact that accessing them locks out userland processes, sometimes for many seconds at a time. The problem is real easy to see, just format and populate a nandfs filesystem, then do something like this mount -r -t nandfs /dev/gnand0s.root /mnt nice +20 find /mnt -type f | xargs -J% cat % > /dev/null and then try to type in another terminal -- sometimes what you're typing doesn't get echoed for 10+ seconds a time. The problem is that the "I/O" on a nand chip is really just the cpu copying from one memory interface to another, a byte at a time, and it must also use busy-wait loops to wait for chip-ready and status info. This is being done by high-priority kernel threads, so everything else is locked out. It seems to me that this is about the same situation as classic ATA PIO mode, but PIO doesn't make a system that unresponsive. I'm curious what techniques are used to migitate performance problems for ATA PIO modes, and whether we can do something similar for nand. I poked around a bit in dev/ata but the PIO code I saw (which surely wasn't the whole picture) just used a bus_space_read_multi(). Can someone clue me in as to how ATA manages to do PIO without usurping the whole system? -- Ian