Date: Thu, 20 Dec 2012 12:07:28 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: freebsd-arm@freebsd.org Subject: Re: nand performance Message-ID: <20121220200728.GK1563@funkthat.com> In-Reply-To: <1355964085.1198.255.camel@revolution.hippie.lan> References: <1355964085.1198.255.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Ian Lepore wrote this message on Wed, Dec 19, 2012 at 17:41 -0700:
> 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?
Looks like the problem is all the DELAY calls in dev/nand/nand_generic.c..
DELAY is a busy wait not letting the cpu do anything else... The bad one
is probably generic_erase_block as it looks like the default is 3ms,
plenty of time to let other code run... If it could be interrupt driven,
that'd be best...
I can't find the interface that would allow sub-hz sleeping, but there is
tsleep that could be used for some of the larger sleeps... But switching
to interrupts + wakeup would be best...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121220200728.GK1563>