On 04/04/12 15:47, Arnd Bergmann wrote: > On Wednesday 04 April 2012, Adrian Hunter wrote: >> On 30/03/12 21:50, Arnd Bergmann wrote: >>> (sorry for the duplicated email, this corrects the address of the android >>> kernel team, please reply here) >>> >>> On Friday 30 March 2012, Arnd Bergmann wrote: >>> >>> We've had a discussion in the Linaro storage team (Saugata, Venkat and me, >>> with Luca joining in on the discussion) about swapping to flash based media >>> such as eMMC. This is a summary of what we found and what we think should >>> be done. If people agree that this is a good idea, we can start working >>> on it. >> >> There is mtdswap. > > Ah, very interesting. I wasn't aware of that. Obviously we can't directly > use it on block devices that have their own garbage collection and wear > leveling built into them, but it's interesting to see how this was solved > before. > > While we could build something similar that remaps blocks between an > eMMC device and the logical swap space that is used by the mm code, > my feeling is that it would be easier to modify the swap code itself > to do the right thing. > >> Also the old Nokia N900 had swap to eMMC. >> >> The last I heard was that swap was considered to be simply too slow on hand >> held devices. > > That's the part that we want to solve here. It has nothing to do with > handheld devices, but more with specific incompatibilities of the > block allocation in the swap code vs. what an eMMC device expects > to see for fast operation. If you write data in the wrong order on > flash devices, you get long delays that you don't get when you do > it the right way. The same problem exists for file systems, and is > being addressed there as well. > >> As systems adopt more RAM, isn't there a decreasing demand for swap? > > No. You would never be able to make hibernate work, no matter how much > RAM you add ;-) Have you considered making hibernate work without swap? -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
