[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201204100840.11763.arnd@arndb.de>
Date: Tue, 10 Apr 2012 08:40:11 +0000
From: Arnd Bergmann <arnd@...db.de>
To: Minchan Kim <minchan@...nel.org>
Cc: 정효진 <syr.jeong@...sung.com>,
"'Alex Lemberg'" <Alex.Lemberg@...disk.com>,
linaro-kernel@...ts.linaro.org, "'Rik van Riel'" <riel@...hat.com>,
linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
"'Luca Porzio (lporzio)'" <lporzio@...ron.com>, linux-mm@...ck.org,
kernel-team@...roid.com, "'Yejin Moon'" <yejin.moon@...sung.com>,
"'Hugh Dickins'" <hughd@...gle.com>,
"'Yaniv Iarovici'" <Yaniv.Iarovici@...disk.com>, cpgs@...sung.com
Subject: Re: swap on eMMC and other flash
On Tuesday 10 April 2012, Minchan Kim wrote:
> I think it's not good approach.
> How long does it take to know such parameters?
> I guess it's not short so that mkfs/mkswap would be very long
> dramatically. If needed, let's maintain it as another tool.
I haven't come up with a way that is both fast and reliable.
A very fast method is to time short read requests across potential
erase block boundaries and see which ones are faster than others,
this works on about 3 out of 4 devices.
For the other devices, I currently use a fairly manual process that
times a lot of write requests and can take a long time.
> If storage vendors break such fields, it doesn't work well on linux
> which is very popular on mobile world today and user will not use such
> vendor devices and company will be gone. Let's give such pressure to
> them and make vendor keep in promise.
This could work for eMMC, yes.
The SD card standard makes it impossible to write the correct value for
most devices, it only supports power-of-two values up to 4MB for SDHC,
and larger values (I believe 8, 12, 16, 24, ... 64) for SDXC, but a lot
of SDHC cards nowadays use 1.5, 3, 6 or 8 MB erase blocks.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists