Messages in this thread | | | Date | Mon, 26 Apr 2010 09:06:13 +0300 | From | Avi Kivity <> | Subject | Re: Frontswap [PATCH 0/4] (was Transcendent Memory): overview |
| |
On 04/25/2010 07:05 PM, Nitin Gupta wrote: > >>> 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. >
Ok. I agree it is silly to go through the block layer and end up servicing it within the kernel.
>>> - 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. >
The same code could also issue the discard?
>> 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? >
Incremental development is fine, especially for ramzswap where the APIs are all internal. I'm more worried about external interfaces, these stick around a lot longer and if not done right they're a pain forever.
-- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
| |