On 04/25/2010 05:46 PM, Avi Kivity wrote: > On 04/25/2010 06:11 AM, Nitin Gupta wrote: >> On 04/24/2010 11:57 PM, Avi Kivity wrote: >> >>> On 04/24/2010 04:49 AM, Nitin Gupta wrote: >>> >>>> >>>>> I see. So why not implement this as an ordinary swap device, with a >>>>> higher priority than the disk device? this way we reuse an API and >>>>> keep >>>>> things asynchronous, instead of introducing a special purpose API. >>>>> >>>>> >>>>> >>>> ramzswap is exactly this: an ordinary swap device which stores every >>>> page >>>> in (compressed) memory and its enabled as highest priority swap. >>>> Currently, >>>> it stores these compressed chunks in guest memory itself but it is not >>>> very >>>> difficult to send these chunks out to host/hypervisor using virtio. >>>> >>>> However, it suffers from unnecessary block I/O layer overhead and >>>> requires >>>> weird hooks in swap code, say to get notification when a swap slot is >>>> freed. >>>> >>>> >>> Isn't that TRIM? >>> >> No: trim or discard is not useful. The problem is that we require a >> callback >> _as soon as_ a page (swap slot) is freed. Otherwise, stale data >> quickly accumulates >> in memory defeating the whole purpose of in-memory compressed swap >> devices (like ramzswap). >> > > Doesn't flash have similar requirements? The earlier you discard, the > likelier you are to reuse an erase block (or reduce the amount of copying). > No. We do not want to issue discard for every page as soon as it is freed. I'm not flash expert but I guess issuing erase is just too expensive to be issued so frequently. OTOH, ramzswap needs a callback for every page and as soon as it is freed. >> Increasing the frequency of discards is also not an option: >> - Creating discard bio requests themselves need memory and these >> swap devices >> come into picture only under low memory conditions. >> > > That's fine, swap works under low memory conditions by using reserves. > Ok, but still all this bio allocation and block layer overhead seems unnecessary and is easily avoidable. I think frontswap code needs clean up but at least it avoids all this bio overhead. >> - We need to regularly scan swap_map to issue these discards. >> Increasing discard >> frequency also means more frequent scanning (which will still not be >> fast enough >> for ramzswap needs). >> > > How does frontswap do this? Does it maintain its own data structures? > frontswap simply calls frontswap_flush_page() in swap_entry_free() i.e. as soon as a swap slot is freed. No bio allocation etc. >>> Maybe we should optimize these overheads instead. Swap used to always >>> be to slow devices, but swap-to-flash has the potential to make swap act >>> like an extension of RAM. >>> >>> >> Spending lot of effort optimizing an overhead which can be completely >> avoided >> is probably not worth it. >> > > I'm not sure. Swap-to-flash will soon be everywhere. If it's slow, > people will feel it a lot more than ramzswap slowness. > Optimizing swap-to-flash is surely desirable but this problem is separate from ramzswap or frontswap optimization. For the latter, I think dealing with bio's, going through block layer is plain overhead. >> Also, I think the choice of a synchronous style API for frontswap and >> cleancache >> is justified as they want to send pages to host *RAM*. If you want to >> use other >> devices like SSDs, then these should be just added as another swap >> device as >> we do currently -- these should not be used as frontswap storage >> directly. >> > > Even for copying to RAM an async API is wanted, so you can dma it > instead of copying. > Maybe incremental development is better? Stabilize and refine existing code and gradually move to async API, if required in future? Thanks, Nitin -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>